1.什么是分库分表
简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。
分表是啥意思？
就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。
比如按照用户id来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200万以内。
分库是啥意思？
就是你一个库一般我们经验而言，最多支撑到并发2000，超过2000一定要扩容了，而且一个健康的单库并发值你最好保持在每秒1000左右，不要太大。
那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
而分库分表是两回事儿，可能是光分库不分表，也可能是光分表不分库，都有可能。
2.为什么要分库分表
分库分表一定是为了支撑高并发、数据量大两个问题的。
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的磁盘、IO、系统开销，甚至性能上的瓶颈。
而一台服务的资源终究是有限的，单表数据超过2000w时查询性能将急剧下降，因此需要对数据库和表进行拆分，从而更好的提供数据服务。
3.如何分表
数据的切分（Sharding）根据其切分规则的类型，可以分为水平切分和垂直切分
-
水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。
例如：我们 userDB 中的 userTable 中数据量很大，那么可以把 userDB 切分为结构相同的多个 userDB：part0DB、part1DB 等，再将 userDB 上的 userTable，切分为很多 userTable：userTable0、userTable1 等，然后将这些表按照一定的规则存储到多个 userDB 上。
优点：
单表的并发能力提高了，磁盘的I/O性能也提高了
如果出现高并发的话，总表可以根据不同的查询，将并发压力发到不同的小表里。
缺点：
无法实现表连接查询 -
垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。
由于数据库的读写都是对同一个库进行操作，所以单库并不能解决大规模并发写入的问题。
例如：我们会建立定义数据库 workDB、商品数据库 payDB、用户数据库 userDB、日志数据库 logDB 等。
优点：
减少增量数据写入时的锁对查询的影响。
由于单表数量下降，常见的查询操作由于减少了需要扫描的记录，使得单表单次查询所需检索的行数变少，减少了磁盘IO、时延变短。
缺点：
无法解决单表数据量太大的问题。
4.有哪些常用的分库分表中间件
分库分表中比较常见的中间件包括：cobar、TDDL、atlas、sharding-jdbc、mycat
cobar：阿里b2b团队开发和开源的，属于proxy层方案。
早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库join和分页等操作。
TDDL：淘宝团队开发的，属于client层方案。
不支持join、多表查询等语法，就是基本的crud语法是ok，但是支持读写分离。目前使用的也不多，因为还依赖淘宝的diamond配置管理系统。
atlas：360开源的，属于proxy层方案。
以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在5年前了。所以，现在用的公司基本也很少了。
sharding-jdbc：当当开源的，属于client层方案。
确实之前用的还比较多一些，因为SQL语法支持也比较多，没有太多限制，而且目前推出到了2.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从2017年一直到现在，是不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
mycat：基于cobar改造的，属于proxy层方案。
支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。
所以综上所述，现在其实建议考量的，就是sharding-jdbc和mycat，这两个都可以去考虑使用。
sharding-jdbc这种client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖；
mycat这种proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
总结
通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多。
但是中大型公司最好还是选用mycat这类proxy层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护mycat，然后大量项目直接透明使用即可。
网友评论