yeg
2026-09-17 00fdc806897e0490db22812bd6b83a7fc0c1bc62
refs
用户 yeg <1347747024@qq.com>
星期四, 九月 17, 2026 09:50 +0800
提交者 yeg <1347747024@qq.com>
星期四, 九月 17, 2026 09:50 +0800
提交00fdc806897e0490db22812bd6b83a7fc0c1bc62
目录 92ee665b9dedf9a0cf53371afc7eac98f6f7fdc0 目录 | zip | gz
parent 91fede1466659416f522de286a2d9e772138ea4f 查看 | 对比
chore(scratch): 按新号方案重写账号错位迁移脚本

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

脚本里写明每段在哪个库执行、前置检查、验收语句,以及刻意不搬的东西(60 秒一换的核销码与登录会话、
种子账号自己的卡),尚未执行:写的是共享服务器库,需备份后在事务内跑。
1个文件已删除
1个文件已添加
146 ■■■■■ 已修改文件
.scratch/db-merge/migrate-to-new-accounts.sql 75 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
.scratch/db-merge/repair-onboardp-talent.sql 71 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史