分库分表介绍：

分库分表的目的是为了系统高并发、高可用。分库和年发表是两回事，两个概念，都是为了防止数据库服务因为同一时间内访问量过大导致宕机而设计的一种应对策略。

一、为什么要分库：

参考：
https://www.cnblogs.com/yanggb/p/11214339.html

一般经验来说，单库支持的最大并发量到2000，最好的运行是1000。如果更高的并发量需求，就需要考虑扩容，将一个库的数据拆分到多个库中，访问的时候根据一定条件访问单库，缓解单库的性能压力。

二、为什么要分表：

分表也是考虑到性能，单表数据量太大的时候sql的执行性能就降低。分表就是按照一定的策略将单表的数据拆分到多表中，查询也按照一定的策略去查询，这样查询的数据范围就缩小了，比如按照用户id来分表，通过id确定哪个表，把表的数据量控制在一定范围内，提升sql语句执行性能。

选型介绍：

参考:

https://www.it610.com/article/1281542839301324800.htm

https://blog.csdn.net/xuheng8600/article/details/80336094

一、三个问题：

1.事务一致性:比如更新10张表，最后一张失败，怎样保证事务

2.字典表问题：字典表维护一个库影响效率，多个库存储出现事务一致性、冗余问题

3.分页查询问题：如果使用mycat，进行分页的时候会面临数据量大的问题

二、中间件对比：

中间件	说明	备注
Atlas	不能实现分布式分表，所有的子表必须在同一台DB的同一个database里且所有的子表必须事先建好，Atlas没有自动建表的功能。
Cobar	必须将拆分后的表分别放入不同的库来实现分布式。	扩展性的问题放弃
TDDL	阿里，功能强大，过于复杂，部分开源。需要评估使用情况，防止过剩。	阿里系
Mycat	国内开源，从入门到放	名气大，已经到头了
heisenberg	百度开源，相对简单，易于管理。	现在不维护了
Oceanus	功能强大，开源，简化开发和配置成功。但产品还不成熟。
vitess	google产品，集群基于ZooKeeper管理，通过RPC方式进行数据处理，可支撑高流量，它还添加了一个连接池，具有基于行的高速缓存，重写SQL查询，更安全
OneProxy	中国厂商产品，稳定性待确认。
Sharding-JDBC	当当最新开源，jdbc层面操作	靠谱

sharding-jdbc这种client层的有点在于不用部署，运维成本就比较低。同时不需要代理层二次转发请求，性能高。缺点是：遇到升级的话，各个系统都重新升级版本再发布，因为各个系统都需要耦合sharding-jdbc依赖。
mycat这种proxy方案缺点在于需要部署，因此运维成本增加。但是优点是各个项目是解耦的，升级的话就是处理中间件就行。

三、概念介绍：

概念	介绍	总结
水平拆分	水平拆分的意思，就是把一个表的数据拆分到多个库的多个表里面去。这里面的每个库的表结构都是一样的，只不过是表中存放的数据不一样，每个库表的数据汇总起来就是全部数据。水平拆分的意义在于将数据均匀地存放在各个库表里，依靠多个库来杠更高的并发，而且还能借助多个库的存储容量来进行扩容	表结构一样、扩容、高并发
垂直拆分	垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表或者多个库上面去，每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里面去，然后将较多的访问频率很低的字段放到另外一个表里面去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里面缓存更多的行，性能也就越好。这个一般在表层面做的较多一些。	拆分字段、利用缓存提升性能

四、两种方案：

方案	优点	缺点
按照range区分	比较常用的是按照时间划分，扩容简单，下个月自动写入库	热点数据会请求到同一个表，起不到高并发
按照hash分发	按照字段hash值均匀分布，平均分配每个库表的数据量和请求压力	扩容麻烦，数据迁移需要重新计算hash值并重新分配

分库分表精辟解读