chore(scratch): 执行账号错位迁移并留档结果

yeg

2026-09-17 d7cb847b8f055c763b45b1795ef5549d70e89c26

chore(scratch): 执行账号错位迁移并留档结果

按用户选定方案执行完毕（一次改动，两个库各一段）：
- 两库登录名 onboardp001 → yangye134，密码未动；
- 服务器库把 benefit_order/order_refund/payment_transaction/verify_record 从种子身份 446 改归新号
  1031，补回本人 EXCELLENT 卡（新 id 1025），card_id 由 240/446 改指 1025。

执行前用 SchemaDump 把相关表导出到 backup/（gitignore）。验收：446 名下订单 0、1031 名下 13
（退款 4/流水 12/核销 5）、无指向 240 的引用；运行中的后端接口 talentId=1031 已能返回这批订单。
脚本拆成 rename-merchant-account.sql 与 move-talent-data-to-1031.sql 两个可直接跑的片段，
README 补记事实、做法与「不要再双向合并」的结论。

 .scratch/db-merge/README.md

@@ -78,3 +78,27 @@
  「0 条待应用」）。要补必须显式开 `outOfOrder=true`，且那 4 条撞列的迁移要先处理——属于其他业务域。
- 服务器库结构上比迁移产物多 28 张历史遗留表（`sys_user`、`payment_record`、`coupon` 等），
  已确认合并后的代码不再引用任何一张，属死表。

## 2026-09-17 修复合并留下的账号错位

合并按主键只插不改，撞车时只统计不覆盖，于是有两处需要收尾（详见 `AccountLookup.java` 排查）：

- `talent_user` 446 被种子账号占用 → 本人账号没搬过去；合并后微信登录新建了 1031（带 openid 与
  手机号），而 13 笔订单 / 4 笔退款 / 12 条流水 / 5 条核销记录仍挂在 446 上，人才端因此看不到数据；
  服务器上 240 号人才卡属于别的人才，订单的 `card_id=240` 也就指错了人。
- `merchant_operator` 的登录名两库都叫 onboardp001（服务器已 rekey 到 id 38），商户 632 的业务数据
  两库一致且完整，只有登录名要改。

已执行（脚本 `rename-merchant-account.sql` + `move-talent-data-to-1031.sql`，执行前用 `SchemaDump`
把相关表导到 `backup/`）：

1. 两库都把登录名改成 `yangye134`（密码未动，实测 hash 长度与前缀不变）；
2. 服务器库把 4 张表的数据从 446 改归 1031，补回本人那张 `EXCELLENT` 卡（新 id 1025），并把
   `benefit_order/order_refund/verify_record` 的 `card_id` 从 240/446 改指到 1025。

验收结果：446 名下订单 0、1031 名下 13（退款 4 / 流水 12 / 核销 5），无指向 240 的卡引用；
种子账号 446 保留自己那张 0434 卡，身份自洽。运行中的后端接口 `talentId=1031` 已能返回这批订单。

**两库从此对同一个人的 talent_id 不同（本机 446 / 服务器 1031），不要再做双向合并**——这正是下面
那条结论的实例。带 id 撞车的表不止这两处（`merchant_operator` 26 行、`merchant_agreement_acceptance`
28 行、`talent_card` 4 行两库内容不同），要长期可用只能选一个库作为唯一事实源。

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

File was deleted

 .scratch/db-merge/move-talent-data-to-1031.sql

New file
@@ -0,0 +1,30 @@
-- 把本人数据从种子身份 446 交给新号 1031。只在服务器库执行（本机库的 446 本来就是本人，勿跑）。
-- 背景与判定见 .scratch/db-merge/README.md 与本次排查：合并按主键只插不改，本人的人才身份行在服务器
-- 被种子账号占用，数据因此挂在 talent_id=446 上；1031 是合并后微信登录新建的新号（带 openid 与手机号）。

start transaction;

-- 现状（人工过一眼：446 是种子账号、1031 是本人新号；订单应为 13）
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;

-- 补回本人的人才卡（内容取自本机 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();

-- 本人数据改归属
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;

-- 卡引用改到新卡：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;

-- 刻意不搬：本机独有的 121 条动态码 / 55 条订单核销码 / 17 条登录会话（运行时自动重建），
-- 以及种子账号 446 名下那张卡（card_no=0434，留在它自己名下）。

 .scratch/db-merge/rename-merchant-account.sql

New file
@@ -0,0 +1,10 @@
-- 商户登录名 onboardp001 → yangye134。两个库都执行（本机库也改，免得再分叉出一个 onboardp001）。
-- 商户 632 的进件/商品/结算卡/门店/订单/退款/核销记录一概不动；密码不动。
-- 前置：'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;
commit;

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