【数据存储】分库分表：角色表按 ID 尾号分片

实战应用：用在哪里

角色表过五千万行后索引膨胀、备份超时，分表是必经之路。按角色 ID 尾号切十张表的方案取其极简：路由是一行取模，扩容是表的复制搬迁——与哈希分片的复杂度换收益不同，尾号分表用最笨的办法解决最普遍的问题。

分表的路由

---按 ID 尾号路由到 10 张表
local TBL_N = 10

function Role.table(userId)
    local tail = tonumber(userId:sub(-1)) or 0
    return "roles_" .. (tail % TBL_N)
end

function Role.find(userId)
    return DB.queryRow(
        "SELECT * FROM ?? WHERE id = ?", Role.table(userId), userId)
end

路由取 ID 的个位尾号对十取模：同一角色的读写永远落在同一张表，路由函数一行搞定且无状态。尾号方案的分布均匀性靠 ID 的生成规则保证——自增 ID 的尾号天然均匀，业务含义的编号（区服前缀）要剥离后再取尾。单表控制在 500 万行内，索引的树高与备份的窗口回到健康区间，五千万行的角色库拆完，单表备份从 2 小时缩到 12 分钟。

扩容的搬迁

---扩容：10 表翻 20 表，搬迁一半
function Role.expand()
    for i = 0, 9 do
        local src = "roles_" .. i
        local dst = "roles_" .. (i + 10)
        -- 双写窗口开启后搬迁
        DB.exec("INSERT INTO ?? SELECT * FROM ??", dst, src)
    end
end

---路由的灰度切换：按尾号分批
function Role.routeGray(userId)
    local tail = tonumber(userId:sub(-1)) or 0
    if Gray.hit(tail, 0.3) then
        return tail >= 10 and tail or tail % 20
    end
    return tail % TBL_N
end

扩容的路径是翻倍：10 表扩 20 表，每张老表的一半数据搬去新表，搬迁的批次按尾号灰度放量。双写窗口覆盖搬迁期：老表新表同写，读按灰度比例切流，切换完成关闭老表写入——扩容的零停机靠的是写路径的冗余而不是迁移的速度。搬迁的对账脚本逐表比对行数与抽样哈希，差一行都不允许切换。尾号方案的短板也直白：尾号的业务倾斜（某些尾号的 ID 段集中发放）会造成表倾斜，倾斜的监控与 ID 发放规则的约束是配套工程。

验证与监控

各表的行数与延迟分位监控，表间的倾斜超 15% 告警；路由的一致性测试，同一 ID 在灰度各阶段的路由结果可追溯。

踩坑记录

尾号曾经取了区服前缀后的第二位，某些批量创建的工作室账号尾号集中，单表挤爆，尾号固定取个位。搬迁的对账曾经只对行数，两行内容互换的错位漏网，抽样的内容哈希补上。双写的写入顺序曾经先新后老，新表的约束报错让老表的写也失败，先老后新的顺序固化。

上线要点

分表的规划一次做十年：表数按十年数据量倒推，翻倍的扩容路径预先写好。路由层对业务透明，分表的存在感止步于存储层。搬迁的窗口放低峰，搬迁速率的限流以主库的 IO 水位为准。

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