为什么MySQL千万级数据必须分库分表
单表数据量突破千万级后，性能断崖式下跌是必然现象。最直观的表现就是简单查询都可能超过1秒响应时间，索引效率下降30%-50%，DDL操作锁表时间从秒级飙升到分钟级。根本原因在于B+树索引层级变深，原本3层的索引可能膨胀到4-5层，每次查询需要多出2-3次磁盘IO。
典型的问题场景包括：
分库分表的核心策略对比
| 策略类型 | 拆分维度 | 适用场景 | 改造难度 |
|---|---|---|---|
| 水平分库 | 按数据行分布 | 单库QPS超过5000 | 高 |
| 水平分表 | 按表数据量切分 | 单表超过2000万行 | 中 |
| 垂直分库 | 按业务模块划分 | 耦合业务解耦 | 极高 |
实际项目中，85%的案例采用水平分表+分库组合方案。比如电商系统通常按用户ID哈希分库，同时在每个库内按订单创建时间范围分表。这种组合能将单表数据量控制在500-1000万行的黄金区间。
源码重构的五个关键步骤
性能优化实战技巧
查询优化首先要解决的是跨分片查询性能问题。对于必须扫描所有分片的count()操作， 采用预聚合方案，在写入时同步更新Redis中的统计值。某金融案例显示，这能使对账报表生成时间从47秒降到0.3秒。
索引重建策略需要特别注意：
慢查询治理有个反直觉的发现：超过60%的慢查询其实发生在单分片内。这时候需要检查是否出现了热点分片，常见于按时间范围分表的场景。解决方案是采用更均匀的哈希分片策略，或者引入动态分片调整机制。
常见踩坑与解决方案
分库分表后最隐蔽的问题是分布式环境下的死锁。不同于单机MySQL的等待图检测，分布式死锁往往表现为超时。某社交平台曾出现过分片A等待分片B，同时分片B又在等待分片A的循环等待，最终导致整个交易链路雪崩。解决方案是引入全局锁超时机制，默认设置为单机MySQL的2-3倍。
另一个高频问题是序列化冲突。当应用服务器使用不同语言开发时，Java的BigDecimal和Go的float64在序列化分片键时可能产生精度差异，导致路由错误。必须在协议层强制规定数字类型的序列化格式，这个坑至少让三个知名团队付出过通宵调试的代价。
处理热点分片问题最有效的办法是在基础哈希分片策略上做智能扩展。对于流量特别大的超级用户，可以设计一个二级路由表，把这些用户的请求自动分散到3-5个不同的分片上。具体实现时，可以在路由层维护一个热点用户名单，当检测到这些用户访问时，自动在其用户ID后追加随机后缀进行二次哈希。某电商平台采用这种方案后，成功将头部用户的订单均匀分布到了多个分片，单分片压力从峰值8000QPS降到了2000-3000QPS的稳定区间。
动态分片调整是另一个值得考虑的方案，特别适合用户流量波动较大的场景。系统可以实时监控各分片的负载情况，当某个分片的QPS持续超过阈值时，自动触发分片扩容。比如把原来映射到分片A的数据，按一定比例迁移到新建的分片A1和A2上。这个过程中需要注意数据迁移的平滑性，可以采用双写机制确保业务不受影响。实践表明，配合智能流量预测算法，这种动态调整机制能让系统自动应对90%以上的突发流量场景。
分库分表后如何保证跨库查询的性能？
对于必须跨分片执行的查询， 采用预聚合方案和结果缓存。在写入时同步更新统计值到Redis，查询时直接读取缓存数据。对于复杂查询，可以改造成两次单分片查询后在内存合并结果，同时使用流式处理避免OOM。实测显示这种方案能使跨分片count()操作从47秒降到0.3秒。
分库分表后分布式事务如何处理？
推荐采用最终一致性方案，基于消息队列实现补偿事务。关键要设计好重试机制和消息去重策略，特别是处理网络分区场景。对于资金类强一致性需求，可以结合TCC模式，但要注意空回滚和幂等性问题，这部分代码通常占整个重构工作量的40%左右。
按用户ID分库后出现热点分片怎么办？
当某些用户产生远超平均水平的流量时，可以在哈希分片基础上引入二级路由。比如将超级用户的订单分散到多个分片，或者采用动态分片调整机制。某社交平台案例显示，这种方案能将热点分片的QPS从15000+降到3000-5000的合理范围。
分库分表后如何高效迁移历史数据？
采用双写+增量同步的方案。先保持旧库写入同时开启新库双写，然后用数据同步工具追平差异。关键是要开发专用的差异检测工具，这个环节能发现80%以上的边界条件问题。对于TB级数据， 分批次迁移，每批控制在500-1000万条数据量。
分库分表后索引设计有什么不同？
必须将分片键作为联合索引的首列，单个分片上的索引数量控制在5个以内。要定期使用pt-index-usage工具清理无用索引，对于分页查询需要特别设计覆盖索引。实测表明，合理的索引设计能使查询性能提升3-5倍。
