一、分库分表概念
1. 分库
随着业务的增长，数据量的增加，很多接口响应时间变得很长，经常出现 Timeout，而且通过升级 MySQL 实例配置已经无法解决问题了，这时候就要分库。
垂直分库：将不同的业务表分在不同的数据库中。
水平分库：水平分库理论上切分起来是比较麻烦的，它是将同一表数据拆分到不同数据库实例中。
2. 分表
分表的应用场景是单表数据量增长速度过快，因为大表会影响查询性能，DDL变更时间很长，影响业务的可用性，同时导致从库延迟很大。但是 MySQL 实例的负载并不高，这时候只需要分表，不需要分库。
垂直分表：表中的字段太多，需要切分字段，一般将不常用的、 数据较大、长度较长的拆分到“扩展表“。
水平分表：单表数据量太大，按某种规则将单表数据拆分到多张表中。从理论上突破了单机数据量的瓶颈，是分库分表的标准解决方案。
二、分片策略
1. 取模分片
比如按主键ID取模，将数据存储到不同的分片中。
- 优点：数据存放比较均匀。
- 缺点：扩容需要大量数据迁移。
2. 按范围分片
比如按日期范围进行分片。
- 优点：扩容不需要迁移数据。
- 缺点：数据存放不均匀，容易产生数据倾斜。
3. 自定义分片
根据业务场景，灵活定制分片策略
分片策略的选取需要考虑如何不迁移数据，实现集群动态扩缩容，同时又能保证数据分布相对均匀。可以采用整体按范围分片，不同范围包含的分片数可以不同，保证扩容时老数据不需要迁移。范围内，按照取模分片，让每个范围内的数据分布大致均匀。
三、是否应该分库分表
以下只是建议，不是绝对的要求。
- 预估数据量：阿里建议3年内单表数据量大于500w或者单表数据文件大于2G，就需要考虑分库分表。
- 数据增长趋势：持续高速增长的数据需要尽早考虑分库分表，并且要预留空间。
- 预估应用场景：由于频繁变更分片键，需要同时做数据迁移，所以，对于分片键变更频繁的数据，不适合进行分库分表。
- 预估业务复杂度：业务逻辑与分片逻辑绑定，会给SQL执行带来很多限制。所以如果对数据的查询逻辑变化非常大，通常不建议分库分表。
四、分库分表面临的问题
- 主键唯一性：当数据被拆分到不同的表中后，主键ID将可能不再满足唯一性。
- 分布式事务：分库分表后，就需要支持分布式事务了。数据库本身为我们提供了事务管理功能，但是分库分表之后就不适用了。如果我们自己编程协调事务，代码方面就又开始了麻烦。
- SQL路由：一条数据插入SQL应该插入到哪个表？这个问题与选取的分片策略息息相关。
- 结果归并：由于查询的数据可能存在于多张表、多个库中，所以需要对查询结果做归并处理。
- 动态扩容：当数据又增长到一定阈值时，就需要考虑扩容，如何实现在不迁移或者少迁移数据的基础上实现动态扩容？
- 联合查询困难：联合查询不仅困难，而且可以说是不可能，因为两个相关联的表可能会分布在不同的数据库，不同的服务器中。
- 多数据源：分库分表之后可能会面临从多个数据库或多个子表中获取数据，一般的解决思路有：客户端适配和代理层适配。
