chore(scratch): 按新号方案重写账号错位迁移脚本

yeg

2026-09-17 00fdc806897e0490db22812bd6b83a7fc0c1bc62

chore(scratch): 按新号方案重写账号错位迁移脚本

放弃「把身份还原到旧 id」，改成用户选定的思路：数据交给新账号。
- 商户侧只需要改登录名 onboardp001 → yangye134（商户 632 的进件/商品/结算卡/订单/退款/核销记录
  两库一致且完整，建新商户反而要把 12 张表的引用全repoint，没有收益）；两个库都改，免得再分叉出
  一个 onboardp001。
- 人才侧的新号就是 1031（合并后微信登录新建、已带 openid 与 19934036931），不用再建；服务器上本人
  业务数据只在 4 张表（订单 13/退款 4/流水 12/核销记录 5），所以本机不必再导数据，只做改归属 +
  补回本人那张 EXCELLENT 卡 + 把 card_id 从 240（服务器上属别的人才）/446（种子卡）改指到新卡。

脚本里写明每段在哪个库执行、前置检查、验收语句，以及刻意不搬的东西（60 秒一换的核销码与登录会话、
种子账号自己的卡），尚未执行：写的是共享服务器库，需备份后在事务内跑。

 .scratch/db-merge/migrate-to-new-accounts.sql

New file
@@ -0,0 +1,75 @@
-- 把散在旧 id 上的数据交给新账号（onboardp001 → yangye134、人才数据 → 1031）。
--
-- 事实（2026-09-17 只读核对）：
--   两库合并是「按主键只插不改」，本人的人才身份行在服务器被种子账号占用（服务器 talent_user 446
--   = 账号434），所以本人那条没搬过去；合并后 9-16 19:02 微信登录新建了 talent_user 1031
--   「普通游客 / 19934036931」（openid 在它身上）。本人的业务数据当时按原主键搬过去了，全部挂在
--   talent_id = 446 上，服务器上只分布在这 4 张表：
--     benefit_order 13、order_refund 4、payment_transaction 12、verify_record 5
--   另外本人的人才卡没搬过去（本机 card 240，服务器 240 是别的人才的卡），订单里的 card_id 因此
--   指向了别人的卡（240×6）或种子账号那张（446×7）。
--
-- 所以本机不需要再导数据：业务数据已经在服务器上，这次只做「改归属 + 把卡补回来」。
-- 商户侧根本不用新号：商户 632 的进件/商品/结算卡/订单/退款/核销记录都是完整且两库一致的，
-- 只有登录账号名要改（密码不动，改完用新账号名 + 原密码登录）。

-- ============================================================================
-- 第 1 段：商户登录名改名 —— 两个库都执行（本机库也改，避免再分叉出一个 onboardp001）
-- 执行前确认 'yangye134' 未被占用（应返回 0 行）：
select id, merchant_id, account from merchant_operator where account = 'yangye134';
-- ============================================================================
start transaction;

update merchant_operator
set account = 'yangye134'
where account = 'onboardp001' and deleted = 0;

-- 验收：select id, merchant_id, account, status from merchant_operator where account = 'yangye134';
commit;

-- ============================================================================
-- 第 2 段：人才数据搬到新号 1031 —— 只在服务器库执行（本机库的 446 本来就是本人，勿跑）
-- ============================================================================
start transaction;

-- 2.1 现状（人工确认：446 是种子账号、1031 是本人新号）
select id, name, mobile from talent_user where id in (446, 1031);
select count(*) as orders_on_446 from benefit_order where talent_id = 446;   -- 应为 13

-- 2.2 给新号补回本人的人才卡（本机 card 240 的内容原样重建；服务器上 card_no 未被占用）
insert into talent_card (talent_id, card_no, card_type, card_level, status, valid_start, valid_end)
values (1031, 'SEEDCARD92348450290200', 'PERSONAL', 'EXCELLENT', 1, '2026-09-12', '2027-09-13');
set @card = last_insert_id();

-- 2.3 本人数据从种子身份搬到新号
update benefit_order       set talent_id = 1031 where talent_id = 446;
update order_refund        set talent_id = 1031 where talent_id = 446;
update payment_transaction set talent_id = 1031 where talent_id = 446;
update verify_record       set talent_id = 1031 where talent_id = 446;

-- 2.4 卡引用改到新卡：240 是本人的卡（服务器上属于别的人才）、446 是种子账号那张
update benefit_order set card_id = @card where talent_id = 1031 and card_id in (240, 446);
update order_refund  set card_id = @card where talent_id = 1031 and card_id in (240, 446);
update verify_record set card_id = @card where talent_id = 1031 and card_id in (240, 446);

commit;

-- 验收（依次应为：446 名下 0 笔订单；1031 名下 13 笔；有效卡是 EXCELLENT；没有指向 240 的卡引用）
--   select
--     (select count(*) from benefit_order where talent_id = 446) as on_446,
--     (select count(*) from benefit_order where talent_id = 1031) as on_1031,
--     (select card_level from talent_card where talent_id = 1031 and status = 1 and deleted = 0) as card_level,
--     (select count(*) from benefit_order where talent_id = 1031 and card_id = 240) as wrong_card_refs;

-- 刻意不搬的东西：
--   * 本机独有的 121 条 talent_dynamic_code / 55 条 order_dynamic_verification_code / 17 条 talent_session
--     —— 都是 60 秒一换的核销码与登录会话，运行时自动重建，补历史没有业务意义，还会再引入一批 id 撞车。
--   * 种子账号 446 名下那张卡（card_no=0434）留在它自己名下，账号434 依旧自洽。
--   * 商户 632 缺的 2 条扫码尝试、1 条商品审核记录（本机独有的审计行），需要的话用 SyncTool 单向补。
--     RowCompare 报的另外 3 张商户券属于商户 631/633，不在这一批。

-- 执行完的现实：
--   * 商户端：用 yangye134 + 原密码登录（密码未动）。
--   * 人才端：重新登录一次即可（1031 已带 openid 与 19934036931），能看到 13 笔订单与 EXCELLENT 卡。
--   * 从此两库对同一个人的 talent_id 不同（本机 446 / 服务器 1031），**不要再做双向合并**——
--     这正是 .scratch/db-merge/README.md 里「应选一个库作为唯一事实源」那条结论。

 .scratch/db-merge/repair-onboardp-talent.sql

File was deleted