【数据存储】合服数据迁移：ID 冲突与数据合并

实战应用：用在哪里

两组服务器人气回落就合服：角色、邮件、行会、排行全部并入同一个库，两个世界的老玩家在一张地图重逢，合服活动的报名量往往是平日的五倍。ID 冲突是头号问题，两边的玩家编号、行会编号各自独立自增，合并方案在迁移前就要定死，边合边想方案必然出大事故。

ID 重映射

function Merge.remapIds(srcDb, dstDb, offsetMap)
    local mapping = {}
    for _, role in ipairs(srcDb:loadRoles()) do
        local newId = dstDb:nextRoleId()
        mapping[role.id] = newId
        dstDb:insertRole(role, newId)
    end
    offsetMap.role = mapping
end

function Merge.remapRefs(srcDb, mapping)
    for _, mail in ipairs(srcDb:loadMails()) do
        mail.to = mapping[mail.to] or mail.to
        mail.from = mapping[mail.from] or mail.from
        dstDb:insertMail(mail)
    end
end

源库每个角色分配目标库新 ID，建立旧到新的映射表，邮件、好友、行会成员等引用字段按映射表二次改写，改写顺序先角色后引用，顺序错了引用就会指到错误的实体。映射表本身落盘保留一年，历史数据的每个旧 ID 都能查到新归属。

重名与排行

function Merge.resolveNames(srcDb, dstDb)
    for _, role in ipairs(srcDb:loadRoles()) do
        if dstDb:nameExists(role.name) then
            role.name = role.name .. ".M"
            QF_MailText(role.mappedId, "您的名字与现有玩家重复，已改为 " .. role.name)
        end
        dstDb:updateName(role.mappedId, role.name)
    end
end

重名自动加服务区后缀并邮件告知，行会同名同理，改名卡作为补偿随邮件附送。合服后战力榜、竞技场分段重新计算，第一次快照在合并事务提交后立刻执行，避免榜单真空期。合服演练在测试环境完整走三遍，第二遍专门测中断恢复，回滚脚本随迁移脚本一起准备，合服公告里的停服时长按演练实测值上浮五成给出。

验证与监控

迁移后行数比对、抽样角色数据校验、首日错误率三道关卡全过才放量入口。

踩坑记录

映射表保留一年的决定在第三个月就派上用场，玩家拿着一年前的旧截图来找装备，旧 ID 到新 ID 的追溯片刻搞定。演练第二遍的中断恢复测试抓到过事务未回滚的引用孤儿，几百封邮件指向已不存在的旧 ID，清理脚本从此成为迁移包的固定成员。合服公告的停服时长按演练实测值上浮五成，实际比公告早开服成为惯例，玩家的等待预期被稳稳接住。迁移窗口选择在周中凌晨三点，避开周末的回流高峰与工作日晚间的活跃时段，停服公告提前七天推送了三次。迁移后的首小时监控看三样东西：登录成功率、邮件到达延迟、聊天频道消息量，三项指标全绿才开放充值入口。行会合并的重名协商做了自助工具，两个同名行会的会长在工具里自行协商改名方案，协商不成系统按创建时间保留长者，规则的确定性减少了人为纠纷。迁移窗口选择在周中凌晨三点，避开周末的回流高峰与工作日晚间的活跃时段，停服公告提前七天推送了三次。迁移后的首小时监控看三样东西：登录成功率、邮件到达延迟、聊天频道消息量，三项指标全绿才开放充值入口。行会合并的重名协商做了自助工具，两个同名行会的会长在工具里自行协商改名方案，协商不成系统按创建时间保留长者，规则的确定性减少了人为纠纷。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。