## 适用场景
多个游戏服务器人气分化，老服合并成一个大服可以聚拢玩家生态、降低运维成本。合服是高危操作：多份玩家数据要合并进同一库，冲突要解决，停机窗口内要完成全部动作，失败还要能回退。清单化的准备是唯一稳妥路径。
## 步骤清单
第一步资产盘点：列出全部源服的数据库规模、账号量、跨服关系，如好友、邮件、帮派、交易行，跨服数据是合并冲突的重灾区。第二步冲突方案设计：主键全部重新映射，新旧编号对照表提前生成；重名角色按规则改名，名字被占的处理策略提前公告玩家；帮派重名的合并或改名规则同样先定。
第三步演练：在测试环境完整走一遍合并流程，用生产数据的副本，演练要覆盖合并后的登录、战斗、社交全功能验证。演练记录每步耗时，用于推算正式窗口。
mysqldump --single-transaction --quick src_server | zstd > src-$(date +%F).sql.zst # 合并脚本内：重名加服标后缀，主键按映射表重写 # 外键与唯一索引在合并期间先禁用，完成后重建校验
第四步正式执行：提前公告停机窗口，全量备份所有源服，逐服执行合并脚本，每步落校验记录。第五步验证开服：核心链路回归，角色数据抽查，补偿发放到位后再放玩家进入。
## 验证方法
数据侧对账：合并前后角色数量、财产总量、道具总量按类核对，数量级必须吻合；抽样对比若干角色的详细数据。功能侧回归：登录、组队、交易、排行、邮件逐项过。客服侧预备：合服后第一天的工单类型提前预判，改名补偿与找回流程文档先备好。
## 注意事项
回退方案必须具体到命令级：备份保存在哪、恢复脚本怎么跑、回退决策由谁在什么条件下触发，窗口内回退要快于放量。顺云云服务器承接合服时，跨服数据的一致性校验与开服首日的监控值守是最后两道保险。
合服后的两周设为观察期，数据与舆情双向跟踪，补偿与公告的节奏提前排好，玩家体验的平稳过渡比合并本身更影响口碑。