共计 2523 个字符，预计需要花费 7 分钟才能阅读完成。
分库分表是高并发高可用系统的一个重要的点，互联网公司面试常常会问道。
为什么要分库分表（设计高并发系统的时候，数据库层面应该如何设计）？
首先要清楚，分库和分表是两回事，是两个独立的概念。分库和分表都是为了防止数据库服务因为同一时间的访问量（增删查改）过大导致宕机而设计的一种应对策略。
为什么要分库
按一般的经验来说，一个单库最多支持并发量到 2000，且最好保持在 1000。如果有 20000 并发量的需求，这时就需要扩容了，可以将一个库的数据拆分到多个库中，访问的时候根据一定条件访问单库，缓解单库的性能压力。
为什么要分表
分表也是一样的，如果单表的数据量太大，就会影响 SQL 语句的执行性能。分表就是按照一定的策略将单表的数据拆分到多个表中，查询的时候也按照一定的策略去查询对应的表，这样就将一次查询的数据范围缩小了。比如按照用户 id 来分表，将一个用户的数据就放在一个表中，crud 先通过用户 id 找到那个表在进行操作就可以了。这样就把每个表的数据量控制在一定范围内，提升 SQL 语句的执行性能。
用过哪些分库分表的中间件？不同的分库分表中间件都有什么优点和缺点？
分库分表常见的中间件有：cobar、TDDL、atlas、sharding-jdbc 和 mycat 等。
cobar
cobar 是阿里的 b2b 团队开发和开源的，属于 proxy 层方案，介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。cobar 并不支持读写分离、存储过程、跨库 join 和分页等操作。早些年还可以用，但是最近几年都没更新了，基本没啥人用，算是淘汰了。
TDDL
TDDL 是淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但是并不支持 join、多表查询等语法。目前使用的也不多，因为使用还需要依赖淘宝的 diamond 配置管理系统。
atlas
atlas 是 360 开源的，属于 proxy 层方案。以前是有一些公司再用的，但是社区最新的维护都在 5 年前了，现在用的公司也基本没有了。
sharding-jdbc
sharding-jdbc 是当当开源的，属于 client 层方案。这个中间件对 SQL 语法的支持比较多，没有太多限制。2.0 版本也开始支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。目前社区也还一直在开发和维护，算是比较活跃，是一个现在也可以选择的方案。
mycat
mycat 是基于 cobar 改造的，属于 proxy 层方案。其支持的功能十分完善，是目前非常火的一个数据库中间件。社区很活跃，不断在更新。相比于 sharding-jdbc 来说，年轻一些，经历的锤炼也少一些。
总结
综上所述，现在建议考量使用的就是 sharding-jdbc 和 mycat。
sharding-jdbc 这种 client 层的优点在于不用部署，因此运维成本也就比较低。同时因为不需要代理层的二次转发请求，性能很高。但是如果遇到升级的话，需要各个系统都重新升级版本再发布，因为各个系统都需要耦合 sharding-jdbc 的依赖。
mycat 这种 proxy 方案的缺点在于需要部署，因此运维成本也就比较高。但是优点在于其对于各个项目是透明（解耦）的，如果要升级的话只需要在中间件处理就行了。
通常来说，这两个方案都是可以选用的。但是建议中小型公司选用 sharding-jdbc 比较好，因为 client 层方案轻便，维护成本低；建议中大型公司选用 mycat 比较好，因为 proxy 层方案可以应对多个系统和项目大量使用，虽然维护成本相对来说会较高，但是中大型公司还缺这点人力吗。
具体如何对数据库进行垂直拆分或水平拆分？
水平拆分的概念
水平拆分的意思，就是把一个表的数据拆分到多个库的多个表里面去。这里面的每个库的表结构都是一样的，只不过是表中存放的数据不一样，每个库表的数据汇总起来就是全部数据。水平拆分的意义在于将数据均匀地存放在各个库表里，依靠多个库来杠更高的并发，而且还能借助多个库的存储容量来进行扩容。
垂直拆分的概念
垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表或者多个库上面去，每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里面去，然后将较多的访问频率很低的字段放到另外一个表里面去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里面缓存更多的行，性能也就越好。这个一般在表层面做的较多一些。
水平拆分和垂直拆分的场景
所谓表层面的拆分，就是分表。具体就是将一个表拆分为 N 个表，让每个表的数据量控制在一定的范围内，保证 SQL 的性能。否则，单表的数据量越大，SQL 的性能也就越差，一般是 200 万行左右，不要太多。如果你的 SQL 越复杂，就尽量让单表的行数越少。
无论是分库还是分表，主流的数据库中间件都是可以支持的。这些中间件可以在你分库分表之后，根据指定的某个字段值自动路由到对应的库和对应的表上面。这时就只要考虑项目如何分库分表就行了。一般来说，垂直拆分，可以在表层面做，即对一些字段特别多的表做一下拆分；水平拆分的话，可能是因为并发承载不了或容量承载不了，也就可以按某个字段去分布到不同的库表里面去。
分库分表的两个方案
这里说一下两种分库分表的方案和它们的优缺点。
1. 按照 range 来分。比如说按照时间范围来分库分表，每个库表中存放的都是连续时间范围的数据。但是这种方式一般很少用，因为很容易会产生热点问题，大量的流量都打在最新的数据上了。这种方案的优点在于扩容的时候非常简单，比如只要预备好每个月都准备一个库就可以了，到了下一个新的月份自动将数据写入新的库。缺点则是，如果大部分请求都是访问最新的数据，那么在这里，分库分表的设计目的就只是简单的扩容，而不是为了应对高并发了。
2. 按照 hash 分发。按照某个字段的 hash 值均匀分散，这个较为常用。优点在于可以平均分配每个库表的数据量和请求压力；缺点在于扩容比较麻烦，因为会存在一个数据迁移的过程，即之前的数据需要重新计算 hash 值并重新分配到不同的库表中。
