决定因素
我们评估一下数据库是否需要做水平拆分要考虑的几个要素主要是
- 主库性能：受限于单个主库的CPU/内存/磁盘IOPS的影响，接近或者达到上限后，需要拆分。
- 容灾方面：减少单个主库宕机对于写入的影响。
- 空间容量：如果你公司的mysql容量比较大，解决了单实例的空间容量限制，但是仍然需要注意特大表的查询性能问题。
别的优化方式
针对以上3点，实际上除了简单的拆分外，我们还需要或者说还可以多考虑一下，有没有更合适的方案
- 主库性能：
1）可以通过读写分离的方式，降低对于写库的读请求量，从而提升对于写入的支撑。
2）优化数据写入模型，减少批量写入（削峰），按照我们线上物理机配置，简单的写入模型支撑5k-7k/s的写入。
有的业务表比较窄，写入可以达到15-20k/s。
- 容灾方面：
1）这个主要要看业务场景，如果业务对于读高可用要求比较高，一般建议是做读写分离，将重要的请求路由至读库。读库数量一般会比写库多N个，在代理层面会做容灾的自动切换。
2）从集群整体的角度看，分库分表实际上是会扩大故障率的。假设单台物理机的SLA是99.99%则2台物理机的SLA约是99.98%10台物理机的SLA就只剩下99.90%。平均每年的故障时间从52分钟提升到525分钟。由于我们采用的通过代理层转发的方案实现分库分表的路由，在有些场景下单个节点故障可能会导致代理整个不可用，从而放大故障的影响范围。
分区的必要条件
按照经验评估，我们的拆分需求主要还是源之于写入能力的要求（比如要求写入tps 10万笔/s 等等）。
如果是基于容灾考虑，我们是建议先做上面提供的优化方案
1）通过读写分离提升读库的SLA
2）减少主库上不必要的读和写，降低故障的概率（物理设备故障无法避免）
3）配置HA自动切换，减少故障影响的时间(这个可以单独沟通)
简而言之，分库分表不是”银弹“，建议先评估清楚后再上船。
Q: 单表超过10亿条数据，需要分库分表吗？
A: 只要业务请求的响应时间满足预期，不需要考虑数量的问题（线上百亿级别的表也不少）
