分库分表
阿里巴巴Java开发手册：单表行数超过500万行或者单表容量超过20GB，才推荐进行分表分库
为什么需要分表分库
- 请求数太高
- 数据查询慢
- 数据量太大
- 单体架构：某张表遇到问题需要修复时，会影响整个库中的所有数据
- MySQL的数据库瓶颈
分库和分表是两个概念
分表
垂直分表
结构不同，数据不同。
现在有一张表，总共43个字段，但是对于程序来说，一般经常使用的字段不过其中的十余个，而这些经常使用的字段则被称之为热点字段，假设此时这张表中的热点字段为18个，剩下的冷字段为25个，那么我们就可以根据冷热字段来对表进行拆分，拆分为18个字段一张表，26个字段一张表（含有一个映射键）
水平分表
结构相同，数据不同
现在有一张表，里面有三千万条数据记录，当基于该表去执行一条在索引上的复杂SQL时，也需要一定时间，至少会比1000万的数据表慢了好几倍，此时可以把这张3000W的表，拆为三张1000W的表。
对一张大表做了水平分表之后，咱们能够很好的控制单表的数据行数，3000W条数据的表和1000W条数据的表，查询速度其实不仅仅只是3倍的差距，数据过了千万级别时，数据量每向上增长一个量级，查询的开销也会呈直线性增长，因此做水平分表时，一般要求控制在500-1200W之间为一张表（阿里500-600w一张）。
总结
分表方案主要是针对单表字段过多或数据过多进行设计的，无论是垂直分表还是水平分表，都必须建立在单库压力不大，但是单表性能不够的情况下进行的
分库
垂直分库
结构不同，数据不同
垂直分库，就是根据业务属性的不同，将单库中具备同一业务属性的表，全部单独拧出来，放在一个单独的库中存储，也就按业务特性将大库拆分为多个业务功能单一的小库，每个小库只为对应的业务提供服务，这样能够让数据存储层的吞吐量呈几何倍增长。
水平分库
结构相同，数据不同
经过垂直分库后，根据不同的业务类型，将访问压力分发到不同的库处理后，虽然在极大程度上提升了数据层的负荷能力，但如果某类业务的并发数依旧很高。通过水平拆分的方案，能够根据压力的不同，分配不同的机器数量，从而使得不同库的抗压性都能满足对应的业务需求，这也就类似于分布式/微服务项目中，对单个服务做集群保证高可用的策略。
水平分库是基于一个节点，然后直接横向拓展，这也就意味着同一业务的数据库，各节点之间的库结构完全相同，但每个节点中的数据是否相同，这就要看你自己去决定了，一般情况下都是不同的，也就是不同节点的库会存储不同范围的数据。
其他分库方案
主从方案/读写分离，写请求发往主节点，读请求发往从节点
多主方案，一般是双主方案
总结
对于分库方案
- 优先考虑主从，主主
- 再考虑垂直分库
- 最后考虑水平分库