经过四道常问面试题，带你了解什么是数据库分库分表

编者语：为了不被误解为：「手里有把锤子，看什么都是钉子！」，说明一下不是什么业务都适合分布式数据库，更不是用了分布式数据库性能就必定能获得扩展。

其次：本文为纯干货，建议先转发、收藏再观看。

分布式数据库已经流行好多年，产品很是众多，其中分布式数据库中间件使用场景最广。本文主要是经过几道关于分库分表的常问面试题带你深刻了解数据库分库分表，但愿对你们可以有所帮助！

一：面试题

• 为何要分库分表？
• 用过哪些分库分表中间件？
• 不一样的分库分表中间件都有什么优势和缺点？
• 大家具体是如何对数据库如何进行垂直拆分或水平拆分的？

2、面试官心理分析

其实这块确定是扯到高并发了，由于分库分表必定是为了支撑高并发、数据量大两个问题的。并且如今说实话，尤为是互联网类的公司面试，基本上都会来这么一下，分库分表如此广泛的技术问题，不问实在是不行，而若是你不知道那也实在是说不过去！

3、面试题剖析

3.一、为何要分库分表？（设计高并发系统的时候，数据库层面该如何设计？）

说白了，分库分表是两回事儿，你们可别搞混了，多是光分库不分表，也多是光分表不分库，都有可能。

我先给你们抛出来一个场景。

假如咱们如今是一个小创业公司（或者是一个 BAT 公司刚兴起的一个新部门），如今注册用户就 20 万，天天活跃用户就 1 万，天天单表数据量就 1000，而后高峰期每秒钟并发请求最多就 10。天，就这种系统，随便找一个有几年工做经验的，而后带几个刚培训出来的，随便干干均可以。

结果没想到咱们运气竟然这么好，碰上个 CEO 带着咱们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！天天活跃用户数 100 万！天天单表数据量 10 万条！高峰期每秒最大请求达到 1000！同时公司还顺带着融资了两轮，进帐了几个亿人民币啊！公司估值达到了惊人的几亿美金！这是小独角兽的节奏！

好吧，没事，如今你们感受压力已经有点大了，为啥呢？由于天天多 10 万条数据，一个月就多 300 万条数据，如今我们单表已经几百万数据了，立刻就破千万了。可是勉强还能撑着。高峰期请求如今是 1000，我们线上部署了几台机器，负载均衡搞了一下，数据库撑 1000QPS 也还凑合。可是你们如今开始感受有点担忧了，接下来咋整呢......

再接下来几个月，个人天，CEO 太牛逼了，公司用户数已经达到 1 亿，公司继续融资几十亿人民币啊！公司估值达到了惊人的几十亿美金，成为了国内今年最牛逼的明星创业公司！天，咱们太幸运了。

可是咱们同时也是不幸的，由于此时天天活跃用户数上千万，天天单表新增数据多达 50 万，目前一个表总数据量都已经达到了两三千万了！扛不住啊！数据库磁盘容量不断消耗掉！高峰期并发达到惊人的 5000~8000！别开玩笑了，哥。我跟你保证，你的系统支撑不到如今，已经挂掉了！

好吧，因此你看到这里差很少就理解分库分表是怎么回事儿了，实际上这是跟着你的公司业务发展走的，你公司业务发展越好，用户就越多，数据量越大，请求量越大，那你单个数据库必定扛不住。

分表

好比你单表都几千万数据了，你肯定你能扛住么？绝对不行，单表数据量太大，会极大影响你的 sql 执行的性能，到了后面你的 sql 可能就跑的很慢了。通常来讲，就以个人经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。

分表是啥意思？就是把一个表的数据放到多个表中，而后查询的时候你就查一个表。好比按照用户 id 来分表，将一个用户的数据就放在一个表中。而后操做的时候你对一个用户就操做那个表就行了。这样能够控制每一个表的数据量在可控的范围内，好比每一个表就固定在 200 万之内。

分库

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

这就是所谓的分库分表，为啥要分库分表？你明白了吧。

3.二、用过哪些分库分表中间件？不一样的分库分表中间件都有什么优势和缺点？

这个其实就是看看你了解哪些分库分表的中间件，各个中间件的优缺点是啥？而后你用过哪些分库分表的中间件。

比较常见的包括：

• cobar
• TDDL
• atlas
• sharding-jdbc
• mycat

3.2.1：cobar

阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序经过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 作分解，而后分发到 MySQL 集群不一样的数据库实例上执行。早些年还能够用，可是最近几年都没更新了，基本没啥人用，差很少算是被抛弃的状态吧。并且不支持读写分离、存储过程、跨库 join 和分页等操做。

3.2.2：TDDL

淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也很少，由于还依赖淘宝的 diamond 配置管理系统。

3.2.3：atlas

360 开源的，属于 proxy 层方案，之前是有一些公司在用的，可是确实有一个很大的问题就是社区最新的维护都在 5 年前了。因此，如今用的公司基本也不多了。

3.2.4：sharding-jdbc

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

3.2.5：mycat

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

小结

综上，如今其实建议考量的，就是 sharding-jdbc 和 mycat，这两个均可以去考虑使用。

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

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

一般来讲，这两个方案其实均可以选用，可是我我的建议中小型公司选用 sharding-jdbc，client 层方案轻便，并且维护成本低，不须要额外增派人手，并且中小型公司系统复杂度会低一些，项目也没那么多；可是中大型公司最好仍是选用 mycat 这类 proxy 层方案，由于可能大公司系统和项目很是多，团队很大，人员充足，那么最好是专门弄我的来研究和维护 mycat，而后大量项目直接透明使用便可。

3.三、大家具体是如何对数据库如何进行垂直拆分或水平拆分的？

水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，可是每一个库的表结构都同样，只不过每一个库表放的数据是不一样的，全部库表的数据加起来就是所有数据。水平拆分的意义，就是将数据均匀放更多的库里，而后用多个库来扛更高的并发，还有就是用多个库的存储容量来进行扩容。

 

垂直拆分的意思，就是把一个有不少字段的表给拆分红多个表，或者是多个库上去。每一个库表的结构都不同，每一个库表都包含部分字段。通常来讲，会将较少的访问频率很高的字段放到一个表里去，而后将较多的访问频率很低的字段放到另一个表里去。由于数据库是有缓存的，你访问频率高的行字段越少，就能够在缓存里缓存更多的行，性能就越好。这个通常在表层面作的较多一些。

 

这个其实挺常见的，不必定我说，你们不少同窗可能本身都作过，把一个大表拆开，订单表、订单支付表、订单商品表。

还有表层面的拆分，就是分表，将一个表变成 N 个表，就是让每一个表的数据量控制在必定范围内，保证 SQL 的性能。不然单表数据量越大，SQL 性能就越差。通常是 200 万行左右，不要太多，可是也得看具体你怎么操做，也多是 500 万，或者是 100 万。你的SQL越复杂，就最好让单表行数越少。

好了，不管分库仍是分表，上面说的那些数据库中间件都是能够支持的。就是基本上那些中间件能够作到你分库分表以后，中间件能够根据你指定的某个字段值，好比说 userid，自动路由到对应的库上去，而后再自动路由到对应的表里去。

你就得考虑一下，你的项目里该如何分库分表？通常来讲，垂直拆分，你能够在表层面来作，对一些字段特别多的表作一下拆分；水平拆分，你能够说是并发承载不了，或者是数据量太大，容量承载不了，你给拆了，按什么字段来拆，你本身想好；分表，你考虑一下，你若是哪怕是拆到每一个库里去，并发和容量都ok了，可是每一个库的表仍是太大了，那么你就分表，将这个表分开，保证每一个表的数据量并非很大。

并且这儿还有两种分库分表的方式：

• 一种是按照 range 来分，就是每一个库一段连续的数据，这个通常是按好比时间范围来的，可是这种通常较少用，由于很容易产生热点问题，大量的流量都打在最新的数据上了。
• 或者是按照某个字段 hash 一下均匀分散，这个较为经常使用。

range 来分，好处在于说，扩容的时候很简单，由于你只要预备好，给每月都准备一个库就能够了，到了一个新的月份的时候，天然而然，就会写新的库了；缺点，可是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。

hash 分发，好处在于说，能够平均分配每一个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，以前的数据须要从新计算 hash 值从新分配到不一样的库或表。

四： 总结

分布式数据库（中间件）的特色就是分库分表，这个比较灵活和容易理解，使用场景最广。 SQL可否将该分布式数据库的性能能力都发挥出来，取决于SQL的写法，通常跟拆分键的行为有关。不一样分布式数据库产品的功能有细节上的差异，可是分库分表的逻辑基本相同，因此上面的分析一样适用于其余分布式数据库（中间件）产品。

我的总结，若有表达不当之处欢迎指正。

舒适提示：部份内容转载自网络

若是你喜欢本文，请转发，想要得到更多信息，请关注