什么时候才真的需要分库分表

分库分表在架构演进里属于重活，一旦拆开，跨表查询、事务、扩容全都要重新设计。动手前值得多问一句：真的到了这一步吗？ 先把索引和缓存做对 多数"数据库撑不住"的案例，问题出在缺索引和缓存用得不对，不在单表容量。慢查询日志里排名靠前的 SQL 补上合适的索引，该进缓存的读拦在缓存里，主库压力常常立刻回落。这条路径的成本是分库分表的零头，便宜的招先用完。 单表规模的经验参考 MySQL 的 B+ 树索引三层大约能撑两千万行的量级，再往上索引层次加深、查询 IO 变多。这只是经验值，不是硬线，关键看三个实际信号：单表体积逼近实例磁盘和内存缓冲池的承载上限；行数增长让深度分页、统计查询慢到影响业务；写入 TPS（每秒事务数）单实例确实顶不住。三条都占了，才谈拆。还没到这一步但硬件吃紧的，先升实例配置；核心库对磁盘 IO 要求极高的，独享物理资源的裸金属服务器也是常规选项——硬件手段永远比架构手段便宜。 真要拆，先想清楚两件事 拆法上，垂直拆是按业务把不同表放进不同库，改动小，通常先做；水平拆是把同一张表按某个字段（比如按 user_id 取模，或按时间范围）分到多表多库，复杂度全在这。水平拆之前必须定好分片键：所有查询尽量带上分片键，否则一次查询扇出到全部分片，性能反而崩掉。分片键选错，后续几乎没有廉价的纠正手段。 拆完的代价清单 跨分片 join 基本没了，靠应用层聚合；跨分片事务改用最终一致性方案；全局唯一 ID 要引入发号器；后续扩容要迁移数据。每一项都是持续的工程成本。分库分表解决的是容量问题，不是性能问题的万能药——大多数业务终其生命周期都到不了必须拆的那一天，把这颗子弹留到真正需要的时候再打。