1 何时分库分表
业务飞速发展，数据规模急速膨胀，单机DB已无法满足业务发展。
传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面难满足海量数据场景。在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘I/O也很可能出现压力，会导致很多问题。
性能
由于MySQL采用 B+树索引，数据量超过阈值时，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
可用性
服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。
业务数据
不同模块的数据，比如用户数据和用户关系数据，全都存储在一个主库中，一旦主库发生故障，所有的模块儿都会受到影响。
主从复制只能减轻读压力，但无法解决容量问题。
影响：
无法执行 DDL，比如添加一列，或者增加索引，都会直接影响线上业务，导致长时间的数据库无响应。
无法备份，与上面类似，备份会自动先 lock 数据库的所有表，然后导出数据，量大了就没法执行了
影响性能与稳定性，系统越来越慢，随时可能会出现主库延迟高，主从延迟很高，且不可控，对业务系统有极大的破坏性影响。
在 4 核 8G 的云服务器上对 MySQL5.7 做 Benchmark，大概可以支撑 500TPS 和 10000QPS，MySQL对于写入性能要弱于数据查询的能力，那么随着系统写入请求量的增长，数据库系统如何来处理更高的并发写请求呢？
这些问题你可以归纳成，数据库的写入请求量大造成的性能和可用性方面的问题，要解决这些问题，你所采取的措施就是对数据进行分片，对数据进行分片，可很好分摊数据库的读写压力，也可突破单机的存储瓶颈，而常见的一种方式就是“分库分表”。
如何使用正确的分库分表呢？很多人会在查询时不使用分区键或在查询时使用大量连表查询。用好分库分表没你想的那么容易。
从读写分离到数据库拆分
主从结构解决了高可用，读扩展，但单机容量不变，单机写性能无法解决。
提升容量 =》分库分表，分布式，多个数据库，作为数据分片的集群提供服务。
降低单个存储节点的写压力。提升整个系统的数据容量上限。
分库分表的好处
分库分表后，每个节点只保存部分的数据，这样可以有效地减少单个数据库节点和单个数据表中存储的数据量，在解决了数据存储瓶颈的同时也能有效的提升数据查询的性能
数据被分配到多个数据库节点上，那么数据的写入请求也从请求单一主库变成了请求多个数据分片节点，在一定程度上也会提升并发写入的性能
2 概念辨析
分库和分表是两码事，可能光分库不分表，也可能光分表不分库。
分库分表是跟着公司业务发展走，业务发展越好，用户越多，数据量越大，请求量越大，那单个数据库一定扛不住。因为单表数据量太大，会极大影响你的 SQL执行性能，到了后面你的SQL可能就跑的很慢。经验来看，单表到几百万时性能就会相对差点，就该分表。
分表
把一个表的数据放到多个表中，然后查询时，就查一个表。
比如按用户id分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200万以内。
分库
单库一般达到2000并发，亟需扩容，合适的单库并发值推荐在1000/s。可将一个库的数据拆分到多个库，访问时就访问一个库。
- 分库分表的由来
3 分库分表中间件
cobar
阿里b2b团队开发，proxy层方案，但已停止维护。
- Github地址
- 不支持读写分离、存储过程、跨库join和分页。
TDDL
淘宝团队开发，client层方案
- Github地址
- 不支持join、多表查询等语法，支持读写分离。
使用的也不多，因为还依赖淘宝的diamond配置管理系统，而且已被阿里云商用，不再开源。
atlas
- Github地址
- 360开源的，proxy层方案，但六年前就不维护了。
sharding-jdbc（shardingsphere）
- Github地址
- 最初由当当开源，client层方案。
SQL语法支持较多，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。被大量公司使用，我司也在用。现在已经升级为Apache组织的项目。
这种client层方案的优点：
不用部署，运维成本低，无需代理层的二次转发请求，性能很高
但遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖。
mycat
- Github地址
- 基于cobar改造，proxy层方案，支持的功能非常完善，社区活跃。但相比sharding jdbc年轻一些。
proxy层方案的缺点：
需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
选型
推荐使用sharding-jdbc和mycat：
- 小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多
- 中大型公司最好还是选用mycat这类proxy层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护mycat，然后大量项目直接透明使用即可
4 微服务架构理论：扩展立方体
- X 轴：clone 整个系统无差别复制，集群
针对全部数据，常见的比如数据库复制，即主从结构，备份和高可用 - Y 轴：解耦不同功能复制，业务拆分
针对业务分类数据，比如垂直的分库分表，即分布式服务化、微服务架构 - Z 轴：拆分不同数据扩展，数据分片
针对任意数据，比如水平分库分表，即分布式架构、任意扩容 
