当单表查询延迟持续超过业务容忍阈值，且索引优化、读写分离、分区等常规手段已无法满足性能要求时，才需要启动分库分表。
分库分表最佳时机怎么判断？先看这三个硬指标
在讨论分库分表之前,先回答一个高频问题：单表数据量到底多大才需要分？很多DBA把千万行当成心理防线，这个数字并非拍脑袋，MySQL底层采用B+树索引，当单表数据量突破千万级后，索引层级大概率从三层升到四层，每多一次磁盘IO，查询延迟就会明显上升，但更准确的判断要看单行大小：如果每行只存几十字节的整形字段，几千万行可能还能扛；如果每行带JSON配置或日志内容，几百万行就可能让缓冲池失效。
除了数据量,三个硬指标更能说明问题：
- 慢查询占比：慢查询日志中，相当一部分SQL是单表全表扫描，且经过索引调整后仍然无改善。
- 数据库连接数：连接池频繁耗尽，应用侧不断报获取连接超时，即使增加连接上限也无法解决。
- CPU与IO瓶颈：数据库CPU长时间打满，磁盘IO队列持续拥堵，而检查过所有慢查和锁等待后，问题依然只集中在某几张核心表上。
业内专家指出,分库分表的最佳时机是在业务高速增长期前完成评估，而不是等到系统告警，可以先画一条业务增长曲线，再把每条曲线对应的核心表数据量、QPS、平均查询耗时列出来，找出增长曲线即将超越当前架构承载力的那个点，这个点就是启动评估的起点。
游戏玩家数据库分库分表实战：哪些表该拆，怎么拆
玩家数据库有鲜明的垂直切分特征,账号表、角色表、背包表跟着user_id走，按哈希算法散到多个库；充值流水表和对局记录表则按时间分片，方便跨月归档，判断哪些表需要拆，不用听感觉，直接看查询模式：
- 是否所有高频查询都带玩家ID？如果是，按玩家维度分库的收益最高。
- 是否存在跨天、跨月的流水统计？如果是，按时间分表是底线。
- 是否有跨装备、跨好友的聚合查询？如果是，尽量避免分库，或者通过冗余表解决。
具体拆分时,建议按两级路由设计，第一级用user_id取模决定去哪个库，第二级再按玩家所在大区或时间范围决定去哪个分片，取模的模数要预留未来半年的增长空间，比如预期玩家量将增长好几倍，那么分片数至少按当前峰值的三倍规划。
分库后最棘手的问题不是数据存放,而是分布式事务，背包道具的发放与玩家账本的扣减，通常不在同一张表里，实际做法是优先将这类强关联表放在同一个分片内，使事务局限在单库内部；如果确实无法同库，则引入最终一致性方案，而不是盲目追求强一致。
分库分表 vs 分区：别急着上中间件
很多团队纠结“分区能解决90%的单表压力，何必分库？”这里有个判断标准：如果单表数据量达到千万级，且所有热点查询都带上分区键，分区依然有效；但一旦查询条件不固定，分区就会失去预剪枝优势，性能直接回到全表扫描。
分区和分库分表的本质区别在于,分区是单实例内部的逻辑拆分，所有数据仍共享同一台机器的磁盘和内存；分库分表是物理隔离，数据分散到多个独立MySQL实例，以下对比更适合做决策参考：
| 对比维度 | 分区 | 分库分表 |
|---|---|---|
| 数据分布 | 单实例、同一存储 | 多实例、物理隔离 |
| 查询透明性 | SQL无需改造 | 需要中间层或路由规则 |
| 扩展能力 | 受单机磁盘和CPU限制 | 可线性扩展 |
| 运维复杂度 | 低，基本透明 | 高，涉及数据迁移 |
| 适用数据量 | 千万级以下 | 亿级或持续增长 |
行业共识认为,分区是分库分表前的最后一道防线，跨过这道防线才需要动刀，但要注意，分区表本身也有坑：全局索引不可跨分区，某些聚合查询会退化到全分区扫描，所以如果业务查询模式已经明显昭示“任何查询都可能不带固定ID”，分区多半不够用。
分库分表中间件选型：成本不只有钱
把分库分表落地,通常需要引入中间件，主流方案有ShardingSphere、MyCat、Vitess等，它们看似开源免费，但隐性成本很高：引入中间件后，配置路由规则、处理分布式事务、排查数据不一致，每一样都需要专人维护，如果团队只有两三个后端，建议先评估运维承载力；如果业务体量足够大，自研或商业化方案反而可能更省钱。
选型时重点看四个能力：
- 路由规则是否支持精确分片+范围分片组合。
- 分布式事务是否走XA,还是支持柔性事务。
- 扩容时是否需要重刷全量数据。
- 社区活跃度和版本迭代速度。
国内游戏团队常用ShardingSphere,轻量场景下MyCat更易上手，但如果业务不允许引入额外中间件，也可以尝试在应用层实现分库逻辑，比如定制一个路由组件，专门负责生成分片路由键，这个方案把复杂度转移到了业务代码，适合表数量不多的小规模场景。
分库分表数据迁移实操：从评估到实施
分库分表不是一锤子买卖,迁移过程比选型更考验工程能力，建议按以下步骤执行：
- 评估是否必须分：导出核心表的历史增长曲线，统计每月新增行数，预测未来三个季度后的总行数。
-
确定分片键
：玩家数据用user_id，流水数据用时间，混合查询场景优先选区分度最高的字段。 - 预分片规划：按目标增长量的两倍预留物理分片，避免一年内又要跑一次全量迁移。
- 双写迁移：旧库写入时同步写入新库，通过Binlog监听或应用层双发，确保数据不丢。
- 校验与灰度切读：对账工具逐表校验新旧库数据，先切5%的流量观察DB和中间件负载，确认无慢查告警后再全量切换。
- 回滚预案：保留旧库至少三天，切换后出现严重性能问题时，立即配置旧库连接，恢复对外服务。
迁移过程中最容易踩的坑是自增主键冲突，多分片各自生成主键时，必须改用全局ID生成策略，比如雪花算法或Redis自增ID，否则合并数据时会出现主键重复，导致同步任务永久卡死。
另一个容易被忽视的点是历史数据迁移顺序,先迁移冷数据，再迁移最近一周的热数据，减少双写压力，冷数据可以批量导出，热数据则通过改动应用层来逐步切流量。
数据库分库分表时机判断：常见问题
单表多少行需要分库分表？
没有固定阈值,多数情况下，千万行以下通过索引优化和读写分离就能解决，超过千万行后，慢查询占比持续上升，才值得动手。
分库分表后还能join吗？
可以,但代价很大，跨库join涉及中间层聚合，性能损耗明显，推荐的做法是设计阶段就按查询维度拆分，把高频join的表分到同一个分片，或者用宽表冗余字段替代。
分库分表与分区能一起用吗？
能,常见做法是先分区再分库，比如流水表按时间分区，再按玩家维度散到不同实例，这套组合方案需要中间件同时支持两层路由，配置复杂度会明显上升，但对超大型玩家库的收益非常直接。