数据库分库分表

为什么分库分表？（设计高并发系统时候，数据库层面该如何设计？）

分库和分表是两回事，大家别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。

分表：

就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户id来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200万以内。

分库：

就是你一个库一般我们经验而言，最多支撑到并发2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒1000左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。

---

分库分表中间件，不同的分库分表中间件有什么优点和缺点？

常见的中间件：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来说，年轻一些，经历的锤炼少一些。

sharding-jdbc这种client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合sharding-jdbc的依赖。
mycat这种proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的在中间件那里搞就好。

---

如何对数据库垂直拆分或水平拆分的

水平拆分：把一个表的数据给弄到多个库的多个表中，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据，水平拆分的意义，就是将数据均匀放到更多库中，然后用多个库来抗高并发，还有就是用多个库的存储容量来进行扩容。
垂直拆分：就是把一个很多字段的表拆分成多个表，或多个库中，每个库的结构都不一样，每个库表都包含部分字段，一般来说，将较少的访问频率很高字段放在一个表，然后将较多的访问频率很低的字段放到另外一个表中，因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多行，性能就越好，这个一般在表层面做的较多。

两种分表分库方式（range&hash）

• range：
  每个库一段连续的数据，这个一般都是按比如时间范围来的，但是这种一般较少用，很容易产生热点问题，大量的流量打在最新的数据上。
  好处在于，后面扩展时，很容易，因为你只要预备好，给每个月都准备一个库，到了一个新的月份，自然就写新的库。
  缺点在于，大部分请求都是访问新的数据，实际生产使用range，要看场景，用户不仅仅访问最新的数据，而是均匀的访问现在的数据以及历史数据。
• hash：
  按照某个字段hash一下均匀分散
  好处在于，可以平均分配每个库的数据量和请求压力。
  坏处在于，扩容起来比较麻烦，会有一个数据迁移的过程。

01_分库分表的由来.png 02_数据库如何拆分.png