分库分表学习

1.为什么要分库分表？

分库分表是两个不同的概念，分表是为了避免单表的数据量太大，执行SQL时影响语句的执行性能；分库主要是为了提高系统的并发量。单个库的并发量最好维持在（1000）左右。

2.数据库如何拆分？

垂直拆分：例如一张表有10个字段，拆分为一张表3个字段（查询频率比较高），和一张表7个字段（查询频率比较低）。因为数据库有缓存，这样缓存区能够存储更多查询频率比较高的字段，进而提高数据库的性能。

水平拆分：将一个表拆分成多个表分布到多个数据库上。一方面提高了系统的整体并发量；提升了执行的SQL语句的性能；

分库分表中间件：协调哪些请求落在哪个数据库上。常用的分库分表中间件：sharding-jdbc，mycat。

sharding-jdbc：当当开源的，属于client层方案。确实之前用的还比较多一些，因为SQL语法支持也比较多，没有太多限制，而且目前推出到了2.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从2017年一直到现在，是不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。

 

mycat：基于cobar改造的，属于proxy层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于sharding jdbc来说，年轻一些，经历的锤炼少一些。

 

所以综上所述，现在其实建议考量的，就是sharding-jdbc和mycat，这两个都可以去考虑使用。

 

sharding-jdbc这种client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖；

 

mycat这种proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

 

通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；