当单库性能瓶颈成为不可忽视的痛点，且常规优化如索引、缓存、读写分离已无法满足业务增长时，就该启动分库分表评估，行业共识认为，单表数据量超过千万级且QPS持续高位是典型信号。
分库分表时机怎么判断？核心指标与决策流程
数据量：千万级是个临界点
当单表数据量达到千万级,索引的B+树深度增加，写入性能下降，查询操作即使走索引，也可能因为数据量大而变慢。单表数据量超过2000万行时，数据库的维护成本显著上升，此时应考虑分表，如何查看数据量？使用MySQL的SHOW TABLE STATUS命令，关注Rows列和Data_length，如果Rows超过千万，且Data_length达到几十GB，就需要警惕。
查询性能：响应时间与QPS
如果单库的QPS长期超过5000,甚至达到上万，数据库连接池会频繁争抢，响应时间从几毫秒飙升到几十毫秒。响应时间超过100毫秒是分库分表的一个参考信号，监控QPS可以使用SHOW GLOBAL STATUS中的Questions或Queries，结合uptime计算，或使用Prometheus+Grafana监控，当核心查询的响应时间出现明显波动，且无法通过加索引优化，说明数据量已经影响性能。
存储容量：逼近硬件上限
单库存储容量达到磁盘的80%以上，扩容频繁，且备份恢复时间过长，分库分表可以横向扩展存储，避免单点瓶颈。磁盘I/O利用率持续超过80%，也是数据库开始“疲劳”的信号，查看磁盘使用率，使用df -h，监控I/O可以通过iostat。
索引与写入瓶颈
数据量增大后,索引维护代价高，写入变慢。每秒写入事务数（TPS）下降，磁盘I/O成为瓶颈，当SHOW ENGINE INNODB STATUS中显示Log sequence number增长过快，且Buffer pool hit rate下降，说明数据库正承受写入压力。
数据库分库分表场景辨析：哪些业务真的需要
电商业务场景：订单与用户
电商的订单表增长极快,订单表通常按用户ID或时间分片，如果订单表日增百万行，一个季度就过亿，此时分库分表是必然，用户表虽然数据量相对稳定，但在高并发登录场景下，单库可能扛不住。按用户ID范围分片，可以均匀分布数据，对于查询带用户ID的场景，分库分表后性能依然良好。
社交/游戏业务场景：消息与日志
社交应用的消息表,用户量大，消息频繁。分库分表通常按用户ID分片，保证同一用户消息在一个分片，便于查询聊天记录，游戏中的玩家日志，数据量巨大且写入频繁，按时间或用户ID分片，可以分散写入热点，如果业务以C端为主，分库分表是常见选择。
IoT/日志场景：时序数据
IoT设备上报数据量极大,但查询模式单一，分库分表可以按设备ID或时间分片，但有时分区表更合适，因为数据冷热分离明显。对于时序数据，如果单表数据量达到亿级，但查询只关心最近数据，可以考虑分表策略，将历史数据迁移到冷存储，在线库只保留活跃数据。
分库分表与分区对比：适用场景与成本差异
分区表：单库内的管理工具
分区表是MySQL内置功能,适用于单库内数据管理。分区表无法突破单库性能瓶颈，且分区键有限制，跨分区查询性能不佳，当数据量达到千万级，分区表可能无法满足性能需求，分区表适用于数据清理场景，如按时间分区，删除旧分区非常快。
分库分表：水平扩展但引入复杂度
分库分表可以水平扩展,但带来分布式事务、跨节点查询、数据一致性等问题。分库分表的成本不仅包括中间件投入，还包括运维复杂度，对于中小团队，使用分库分表可能得不偿失，选择分库分表时，需评估中间件（如ShardingSphere、MyCAT、Vitess）的成熟度与团队能力。
对比表格
| 维度 | 分区表 | 分库分表 |
|---|---|---|
| 扩展性 | 单库内扩展，受限于单库性能 | 横向扩展，多节点 |
| 数据量 | 适合千万级以下 | 适合亿级以上 |
| 复杂度 | 低，内置于数据库 | 高，需中间件或应用层 |
| 跨节点查询 | 不支持跨分区高效查询 | 需聚合 |
| 事务 | 本地事务 | 分布式事务 |
| 成本 | 无额外成本 | 硬件、中间件、运维成本 |
如何选择
- 数据量在千万级以下,且单库性能尚可：优先考虑分区表。
- 数据量达到亿级,QPS过万：分库分表是必然选择。
- 业务对强一致性要求高：谨慎使用分库分表，考虑其他方案如NewSQL。
- 短期数据增长快但长期稳定：分库分表可应对瓶颈，但需评估运维投入。
分库分表实施前的准备工作
容量评估与预估
根据业务增长趋势,预估未来1-2年的数据量。预估分片数量，确保每个分片数据量在合理范围（如500万-1000万行），使用公式：总数据量 / 每分片数据量 = 分片数，考虑未来扩容，使用一致性哈希算法，初始分片数可设为2的幂次（如8、16、32），方便后续翻倍扩容。
分片键选择策略
分片键直接影响查询效率。常见分片键有用户ID、订单ID、时间字段，选择分片键需考虑业务查询模式，尽量让大部分查询命中单个分片，订单表按用户ID分片，查询用户订单时只需访问一个分片，如果按时间分片，则需注意数据倾斜，避免热点集中在最新分片。
分片算法选择
- 取模：简单，但扩容时数据迁移量大。
- 一致性哈希：扩容时只迁移部分数据，适合在线系统。
- 范围分片：按时间或ID范围，易于管理，但可能数据倾斜。
数据迁移方案
在线数据迁移是个挑战。使用双写策略或数据同步工具，如Canal、DataX，步骤：
- 搭建新库,开始同步历史数据。
- 应用双写,新旧库同步同时写入。
- 校验数据一致性,使用工具对比数据。
- 逐步切换读流量,先切换一部分用户，观察性能。
- 最终切换全部流量,下线旧库。
需要制定回滚方案，确保数据一致性。迁移过程中，建议使用灰度发布，逐步验证。
中间件选型考虑
- ShardingSphere：Java生态成熟，支持分片、读写分离、分布式事务。
- MyCAT：基于MySQL协议，兼容性好，但社区活跃度一般。
- Vitess：云原生，适合大规模场景，但学习成本高。
选择时考虑团队语言、运维能力、社区支持。对于中小团队，优先选择ShardingSphere，因为文档丰富，社区活跃。
分库分表时机判断常见问题解答
问题1：分库分表后如何保证数据一致性？
分布式事务方案如XA协议、TCC、Saga，对于大多数业务，使用最终一致性方案，结合消息队列补偿，可满足要求。强一致性场景需谨慎评估分库分表必要性，可考虑使用NewSQL数据库如TiDB。
问题2：分库分表后如何做跨分片查询？
避免跨分片查询,将常用查询条件带上分片键，如果必须跨分片，使用中间件聚合结果，或建立全局索引表。跨分片查询性能低于单分片查询，设计时尽量让业务查询路由到单个分片。
问题3：分库分表后扩容如何操作？
扩容时增加分片,重新分配数据。使用一致性哈希算法可以减少数据迁移量，预分片策略可应对未来扩容，但需估算初始分片数量，扩容步骤：
- 增加新分片节点。
- 数据迁移,重新哈希。
- 切换路由,逐步接管流量。
- 验证数据一致性,监控性能。
分库分表不是银弹，判断时机需结合业务数据量、性能指标与增长趋势，在常规优化失效时果断决策，避免过早或过晚引入。