From d7cb847b8f055c763b45b1795ef5549d70e89c26 Mon Sep 17 00:00:00 2001 From: yeg <1347747024@qq.com> Date: 星期四, 17 九月 2026 09:52:54 +0800 Subject: [PATCH] chore(scratch): 执行账号错位迁移并留档结果 --- /dev/null | 75 ------------------------- .scratch/db-merge/README.md | 24 ++++++++ .scratch/db-merge/move-talent-data-to-1031.sql | 30 ++++++++++ .scratch/db-merge/rename-merchant-account.sql | 10 +++ 4 files changed, 64 insertions(+), 75 deletions(-) diff --git a/.scratch/db-merge/README.md b/.scratch/db-merge/README.md index f72ec35..662c45d 100644 --- a/.scratch/db-merge/README.md +++ b/.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 行两库内容不同），要长期可用只能选一个库作为唯一事实源。 diff --git a/.scratch/db-merge/migrate-to-new-accounts.sql b/.scratch/db-merge/migrate-to-new-accounts.sql deleted file mode 100644 index a27a011..0000000 --- a/.scratch/db-merge/migrate-to-new-accounts.sql +++ /dev/null @@ -1,75 +0,0 @@ --- 把散在旧 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 里「应选一个库作为唯一事实源」那条结论。 diff --git a/.scratch/db-merge/move-talent-data-to-1031.sql b/.scratch/db-merge/move-talent-data-to-1031.sql new file mode 100644 index 0000000..55f2976 --- /dev/null +++ b/.scratch/db-merge/move-talent-data-to-1031.sql @@ -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，留在它自己名下）。 diff --git a/.scratch/db-merge/rename-merchant-account.sql b/.scratch/db-merge/rename-merchant-account.sql new file mode 100644 index 0000000..7c1c164 --- /dev/null +++ b/.scratch/db-merge/rename-merchant-account.sql @@ -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'; -- Gitblit v1.7.1