一、分库分表
分库场景：如果数据库的查询QPS过高，就要考虑拆库，比如：查询QPS为3500，假设单库可以支撑1000个连接数，那么就考虑拆分成4个库，来分散查询压力。
分库分表场景：
切分方案 解决的问题 只分库不分表 数据库读/写 QPS过高，数据库连接数不足 只分表不分库 单表数据量过大，存储性能遇到瓶颈 既分库又分表 连接数不足+存储性能遇到瓶颈
二、数据切分方法
水平切分
这是一种按业务维度切分的方式，比如，常见的按会员维度进行切分，根据一定规则，把不同会员的数据散落在不同的库表中。
垂直切分
垂直切分可以理解为：把一张表的不同字段拆分到不同的表中
三 分库分表后会遇到哪些坑
事务一致性
解决办法：XA协议、两阶段提交、TCC，通常使用最终一致性的方案，采用事务补偿的方式
分页、排序问题
1）如果排序字段恰好是分片字段，通过分片规则就可以定位到分片的位置；如果排序字段是非分片字段，就需要在不同的分片点中将数据进行排序再返回；然后不同分片的数据汇集到一起再进行汇总和排序，最终返回给用户。
2）用ES
全局唯一主键问题
分布式id生产方案
四 分库分表后历史数据如何做迁移
一般采用【双写】的方式进行迁移
1.增量的消息往新表和老表各写一份
2.将旧表的数据迁移至新库
3.迟早新表的数据会赶上旧表的数据
4.校验新表数据和老表数据是否对得上
5.开启双读（一部分流量走新表，一部分流量走老表），相当于灰度的过程
6.读流量全部切换至新表，停止旧表的写入
7.提前准备回滚机制，临时切换失败能恢复正常业务以及修复数据的相关程序
五 分库分表中间件对比
Sharding-jdbc：client层方案
优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高（轻便，维护成本低，比较推荐中小型公司项目使用）
缺点：如果遇到升级，各个系统都需要重新升级版本再发布，各个系统都需要耦合Sharding-jdbc的依赖
Mycat：proxy层方案
- 缺点： 需要部署，自己要运维一套中间件，运维成本高
- 优点：对于各个项目都是透明的，如果遇到升级问题，自己中间件搞定就行了（推荐大型公司项目使用）。