split_table.md

分库分表

• 分库分表，通常指定表中的一个字段为分区KEY，按Range或是Hash的方式进行拆分。

• 进行分库分表是为了让业务有更好、更快的扩展能力，以适应业务发展需要。同时也方便增删改字段、数据备份恢复等。如果业务稳定，也可以不用进行太多、太复杂的分表方案。服务器性能足够，架构、业务设计也合理的话，MySQL处理上亿数据量的单表也是绰绰有余。

• 单表数据容量限制规则

• 无CHAR/VARCHAR/TEXT/BLOB的可以考虑千万到亿级左右，否则不建议超过千万级别。

• 单表空间物理大小限制规则 ： 业界最佳实践： 单表行数在2000万行或是单表容量超过5G，推荐分库分表，更方便运维及使用。

• 分表参考案例

  例如有个业务表计划分成100个子表，那么可以分成 10个实例各10个子表； 或者100个实例各1个子表。
  

**备注：**在做分库分表设计时，要考虑后期扩容怎么处理。是通过移动库的形式做扩容，或是通过移动表的形式扩容。是倍数扩容，或是基数扩容，都需要提前规划好。从而设计不同的拆分规则，才能更适用自已的业务。

分库分表中间件推荐

...

a. 为什么决定进行分库分表

1. 根据业务类型，和业务容量的评估，来选择和判断是否使用分库分表。
2. 当前数据库本事具有的能力，压力的评估。
3. 数据库的物理隔离，例如减少锁的争用、资源的消耗和隔离等。
4. 热点表较多,并且数据量大，可能会导致锁争抢，性能下降。
5. 数据库的高并发，数据库的读写压力过大，可能会导致数据库或系统宕机。
6. 数据库（MySQL5.7以下）连接数过高，会增加系统压力。
7. 单表数据量大，如SQL使用不当，会导致io随机读写比例高。查询慢（大表上的B+树太大，扫描太慢，甚至可能需要4层B+树）
8. 备份和恢复时间比较长。

b. 遇到什么问题

1. 全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好。
2. 分片键的选择。如没有选择好，可能会影响SQL执行效率。
3. 分布式事物，中间价产品对分布式事物的支持力度。
4. 对于开发来说，需要进行业务的拆分
5. 对于开发来说，部分SQL不兼容则需要代码重构，工作量的评估
6. 对于开发来说，跨库join，跨库查询

c. 如何解决

1. 使用全局分号器。或者使用全局唯一id，（应用生成顺序唯一int类型做为全局主键）。
2. 应用层来判断唯一索引。
3. 配合应用选择合适的分片键，并加上索引。
4. 配合应用，配合开发，对不兼容SQL的进行整改。