传奇合服后的数据库迁移，注意点集中在备份、去重、表结构调整和校验回滚这四件事上，特别是ID冲突和孤儿数据，处理不好就是灾难。
很多朋友问我传奇合服后数据库迁移注意哪些点，我通常先反问一句：你上一次完整备份是什么时候？合服不是两个库拼一起那么简单，玩家数据错乱、充值丢失、角色失踪，绝大多数都出在迁移前没想清楚逻辑，下面按实际干活顺序,把这几个坑一个个说透。
合服前不把这些事做扎实，迁移就是给自己挖坑
备份要“双份异地”，不是导出一份SQL就完事
源库和目标库都要备份，而且备份文件必须放到不同的物理机器上，之前见过有人两个备份都拖在同一个服务器硬盘里，迁移到一半磁盘满，整个库只剩半条命，不要把宝压在“我操作很稳”上,多一份异地备份就是多一条后路。
停机窗口选对，公告写清
凌晨4点到6点是人最少的时候，这时候合服压力最小，但别忘了提前在官网和游戏内发公告，讲清楚具体停服时段和可能出现的情况，传奇玩家半夜还在蹲boss，你突然踢他下线,下一秒客服就爆炸。
先盘表关系，再动手指
把源库的表结构整体过一遍，重点看主外键、唯一索引、自增ID，合服不是A库加B库，而是把两张相同结构的表合并成一张，自增ID冲突是第一个要解决的问题，不是写个UPDATE就能混过去,关联表必须一起改。
传奇合服数据库迁移中最容易忽略的细节
玩家ID冲突和自增主键怎么处理
两个服的角色ID都是从1开始，直接导入必炸，常见做法是给源库每个角色ID加一个偏移量，比如原ID是2000，新ID就变成2000加1000000，偏移量必须大于源库最大ID,防止新库之后的写入撞上。
然后所有子表的外键都要跟着改，背包、技能、任务、好友、邮件，这些表里存的owner_id全是旧角色ID,漏改一个就会变成孤儿数据。
角色重名和行会重名要定规则
两个服都有叫“战神”的玩家，怎么处理？行业共识认为，保留等级高的，等级一样保留开服时间早的，被系统改名的玩家发一张改名卡,别让玩家自己硬扛损失。
行会名问题同样如此，但注意行会ID才是真正的主链，名字只是显示字段，合并行会数据时，行会ID也要做偏移更新，然后公告写清楚“行会名被系统修改，请联系GM处理”,避免玩家误以为行会解散了。
邮件表和排行榜表是重灾区
邮件表经常被忽略，合服后未读邮件全丢，玩家直接跳脚，邮件表里的owner_id字段必须跟着角色ID迁移，一个都不能漏，有些邮件还有附件,附件表也要联查。
排行榜表如果直接复制过去，新服的榜单会消失，正确的做法是合服后重新从角色表算一遍战力、等级、杀怪数，不要搬旧榜，旧榜数据可能还有合服前的残留,直接搬属于自欺欺人。
跨服数据表不要重复导入
涉及跨服玩法的服，合服时那份跨服数据表可能和原库结构一致，但跨服表往往有独立的跨服唯一标识，如果不加区分直接导入，会出现重复记录，导致跨服排位错乱，业内专家指出，跨服表应单独备份、单独评估,不能混在普通业务表里批量处理。
传奇合服数据库迁移怎么操作才算稳妥
这个操作流程我基本固定下来，按四步走,顺序乱了就会出鬼。
第一步：停服锁库
先停游戏网关，断开所有业务线程到数据库的连接，然后把数据库设为只读状态，别忘了关掉定时任务和自动备份脚本，那些后台任务趁你不注意写一条数据进去,后面校验就又白干了。
第二步：全量导出与分表导入
用mysqldump导出源库结构，先导结构再导数据，目标库先把相关表清空，注意truncate和delete的区别，truncate会重置自增ID，delete不会，如果目标库里还有旧数据,直接truncate。
分表导入也很关键，别一个SQL文件几个GB直接跑，容易超时，按表大小拆成若干个批次，先导入小表，再导大表,每导完一张表记录一下行数。
第三步：按业务逻辑清洗数据
清洗不是光删重复行，比如两个服都有ID为1001的角色，但这是两个不同的玩家，你要决定保留哪个，另一个先插入临时表，标记为“待处理”,留给运营定夺。
然后重建所有关联关系，角色ID偏移后，背包、技能、任务、好友、邮件等表的外键全部UPDATE，接着处理孤儿数据：找不到父记录的子记录直接删除，但删除前先统计数量，做到心里有数，一旦删错了,备份还能救回来。
第四步：自动化校验和人工抽检
写几条SQL做总数校验，比如源库A加源库B的角色数，减去重复数，必须等于目标库角色数,不相等就逐表排查。
人工抽检部分，从两个服各抽几个高等级角色，对照元宝、战力、VIP等级和背包关键装备，登录游戏跑一遍日常流程，登录、打怪、交易、邮件领取,一样都不能省。
| 校验项 | 通过标准 |
|---|---|
| 角色总数 | 等于两源库去重后的数量 |
| 元宝总量 | 与两源库消费后余额总和一致 |
| 背包装备 | 抽样100件无丢失 |
| 行会成员 | 每个行会人数与合服前一致 |
合服后数据校验不过关，怎么快速定位问题
校验发现差异别慌，先分模块排查，登录、交易、行会、邮件、排行榜分开查,一次查一个模块。
然后看binlog日志，重点查合服窗口内有没有可疑写入，如果源库还在继续接收数据，那可能是停机窗口没控制好，最后用两个源库的备份做对比，找出最早出现差异的时间点,从那个点往后查。
备份至少保留七天
合服后两周内都属于高危期，一周备份是最低要求，备份文件必须能直接恢复，别只留着不能用的，建议提前在测试机上演练一次完整恢复流程,确保脚本没问题。
回滚什么时候用
如果大量数据错误且无法修复，立即停服回滚，回滚前把错误数据截个图，方便运营跟玩家解释，回滚后该补偿就补偿，这是公关问题,不是技术问题。
说白了，传奇合服后数据库迁移拼的不是炫技，而是备份、清洗、校验这三板斧够不够扎实，你把这些点都排一遍,基本就能安稳落地。
传奇合服后数据库迁移问题答疑
合服后角色消失了能恢复吗？
能，只要备份没丢，从源库备份里找到该角色数据，根据角色ID和zone_id定位，手动插入到目标库，注意重新生成新的角色ID，并同步更新背包、邮件、任务等子表。
合服后数据库迁移速度太慢怎么办？
先看索引是不是太多了，导入时先删掉非必要索引，导入完再重建，也可以拆表并行导入，把几个大表分开用多线程跑，最实用的办法是升级磁盘IO，机械硬盘换SSD,速度提升非常明显。
合服后元宝数据对不上是哪出了问题？
大多数是重复充值订单导致的，两个服的支付回调在合服时同时写入，或者去重逻辑没有覆盖跨服的唯一订单号，检查订单表的联合唯一索引,确保同一笔单号在两个服只能保留一条。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/757367.html
