DB分库分表习题集

1. 简述为什么要分库 ？

 正确回答通过率：88.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

如果业务量剧增，数据库可能会出现性能瓶颈，这时候我们就需要考虑拆分数据库。从这两方面来看：
磁盘存储
业务量剧增，MySQL单机磁盘容量会撑爆，拆成多个数据库，磁盘使用率大大降低。
并发连接支撑
我们知道数据库连接数是有限的。在高并发的场景下，大量请求访问数据库，MySQL单机是扛不住的！高并发场景下，会出现too many connections报错。
当前非常火的微服务架构出现，就是为了应对高并发。它把订单、用户、商品等不同模块，拆分成多个应用，并且把单个数据库也拆分成多个不同功能模块的数据库（订单库、用户库、商品库），以分担读写压力。

2. 简述为什么要分表 ？

 正确回答通过率：92.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

假如你的单表数据量非常大，存储和查询的性能就会遇到瓶颈了，如果你做了很多优化之后还是无法提升效率的时候，就需要考虑做分表了。一般千万级别数据量，就需要分表。
这是因为即使SQL命中了索引，如果表的数据量超过一千万的话，查询也是会明显变慢的。这是因为索引一般是B+树结构，数据千万级别的话，B+树的高度会增高，查询就变慢啦

3. 解释什么时候考虑分库分表？

 正确回答通过率：81.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 初级

对于MySQL，InnoDB存储引擎的话，单表最多可以存储10亿级数据。但是的话，如果真的存储这么多，性能就会非常差。一般数据量千万级别，B+树索引高度就会到3层以上了，查询的时候会多查磁盘的次数，SQL就会变慢。
阿里巴巴的《Java开发手册》提出：
单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
那我们是不是等到数据量到达五百万，才开始分库分表呢？
不是这样的，我们应该提前规划分库分表，如果估算3年后，你的表都不会到达这个五百万，则不需要分库分表。
MySQL服务器如果配置更好，是不是可以超过这个500万这个量级，才考虑分库分表？
虽然配置更好，可能数据量大之后，性能还是不错，但是如果持续发展的话，还是要考虑分库分表
一般什么类型业务表需要才分库分表？
通用是一些流水表、用户表等才考虑分库分表，如果是一些配置类的表，则完全不用考虑，因为不太可能到达这个量级。

4. 如何分库分表 ？

  正确回答通过率：51.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

分库分表的核心理念就是对数据进行切分（Sharding），以及切分后如何对数据的快速定位与查询结果整合。而分库与分表都可以从：垂直（纵向）和 水平（横向）两种纬度进行切分。

5. 简述什么是数据库垂直切分 ？

  正确回答通过率：64.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

垂直切分有 垂直 分库 和 垂直分表

1、垂直分库
垂直分库相对来说是比较好理解的，核心理念就四个字：专库专用。
按业务类型对表进行分类，像订单、支付、优惠券、积分等相应的表放在对应的数据库中。开发者不可以跨库直连别的业务数据库，想要其他业务数据，对应业务方可以提供 API 接口，这就是微服务的初始形态。
垂直分库很大程度上取决于业务的划分，但有时候业务间的划分并不是那么清晰，比如：订单数据的拆分要考虑到与其他业务间的关联关系，并不是说直接把订单相关的表放在一个库里这么简单。
在一定程度上，垂直分库似乎提升了一些数据库性能，可实际上并没有解决由于单表数据量过大导致的性能问题，所以就需要配合水平切分方式来解决。

2、垂直分表
垂直分表是基于数据表的列（字段）为依据切分的，是一种大表拆小表的模式。
例如：一张 order 订单表，将订单金额、订单编号等访问频繁的字段，单独拆成一张表，把 blob 类型这样的大字段或访问不频繁的字段，拆分出来创建一个单独的扩展表 work_extend ，这样每张表只存储原表的一部分字段，再将拆分出来的表分散到不同的库中。
img
我们知道数据库是以行为单位将数据加载到内存中，这样拆分以后核心表大多是访问频率较高的字段，而且字段长度也都较短，因而可以加载更多数据到内存中，来增加查询的命中率，减少磁盘IO，以此来提升数据库性能。
垂直切分的优点：
业务间数据解耦，不同业务的数据进行独立的维护、监控、扩展。
在高并发场景下，一定程度上缓解了数据库的压力。
垂直切分的缺点：
提升了开发的复杂度，由于业务的隔离性，很多表无法直接访问，必须通过接口方式聚合数据。
分布式事务管理难度增加。
数据库还是存在单表数据量过大的问题，并未根本上解决，需要配合水平切分

6. 简述什么是数据库水平切分 ？

  正确回答通过率：69.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

垂直切分还是会存在单库、表数据量过大的问题，当我们的应用已经无法在细粒度的垂直切分时，
依旧存在单库读写、存储性能瓶颈，这时就要配合水平切分一起了，水平切分能大幅提升数据库性能。

1、水平分库
水平分库是把同一个表按一定规则拆分到不同的数据库中，每个库可以位于不同的服务器上，以此实现水平扩展，是一种常见的提升数据库性能的方式。
这种方案往往能解决单库存储量及性能瓶颈问题，但由于同一个表被分配在不同的数据库中，数据的访问需要额外的路由工作，因此系统的复杂度也被提升了。
例如下图，订单DB_1、订单DB_1、订单DB_3 三个数据库内有完全相同的表 order，我们在访问某一笔订单时可以通过对订单的订单编号取模的方式 订单编号 mod 3 （数据库实例数） ，指定该订单应该在哪个数据库中操作。

2、水平分表
水平分表是在同一个数据库内，把一张大数据量的表按一定规则，切分成多个结构完全相同表，而每个表只存原表的一部分数据。
例如：一张 order 订单表有 900万数据，经过水平拆分出来三个表，order_1、order_2、order_3，每张表存有数据 300万，以此类推。
水平分表尽管拆分了表，但子表都还是在同一个数据库实例中，只是解决了单一表数据量过大的问题，并没有将拆分后的表分散到不同的机器上，还在竞争同一个物理机的CPU、内存、网络IO等。要想进一步提升性能，就需要将拆分后的表分散到不同的数据库中，达到分布式的效果。
水平切分的优点：
解决高并发时单库数据量过大的问题，提升系统稳定性和负载能力。
业务系统改造的工作量不是很大。
水平切分的缺点：
跨分片的事务一致性难以保证。
跨库的join关联查询性能较差。
扩容的难度和维护量较大，（拆分成几千张子表想想都恐怖）。

7. 请问什么是一定规则 ？

 正确回答通过率：58.0%

[ 详情 ] 推荐指数： ★★ 试题难度： 中级

一定规则 ，这个规则其实是一种路由算法，就是决定一条数据具体应该存在哪个数据库的哪张表里。
常见的有 取模算法 和 范围限定算法

8. 请详细解释分库分表规则的取模算法 ？

  正确回答通过率：73.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

按字段取模（对hash结果取余数 (hash() mod N)，N为数据库实例数或子表数量）是最为常见的一种切分方式。
还拿 order 订单表举例，先对数据库从 0 到 N-1进行编号，对 order 订单表中 work_no 订单编号字段进行取模，得到余数 i，i=0存第一个库，i=1存第二个库，i=2存第三个库…以此类推。
这样同一笔订单的数据都会存在同一个库、表里，查询时用相同的规则，用 work_no 订单编号作为查询条件，就能快速的定位到数据。

优点：
数据分片相对比较均匀，不易出现请求都打到一个库上的情况。
缺点：
这种算法存在一些问题，当某一台机器宕机，本应该落在该数据库的请求就无法得到正确的处理，这时宕掉的实例会被踢出集群，此时算法变成hash(userId) mod N-1，用户信息可能就不再在同一个库中了。

9. 请详细解释分库分表规则的范围限定算法 ？

  正确回答通过率：72.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

按照 时间区间 或 ID区间 来切分，比如：我们切分的是用户表，可以定义每个库的 User 表里只存10000条数据，第一个库只存 userId 从1 ~ 9999的数据，第二个库存 userId 为10000 ~ 20000，第三个库存 userId 为 20001~ 30000…以此类推，按时间范围也是同理。
优点：
单表数据量是可控的
水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移
能快速定位要查询的数据在哪个库
缺点：
由于连续分片可能存在数据热点，比如按时间字段分片，可能某一段时间内订单骤增，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询。

10. 数据库分库后，事务问题如何解决 ？

 正确回答通过率：55.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

库分表后，假设两个表在不同的数据库，那么本地事务已经无效啦，需要使用分布式事务了
常用的分布式事务解决方案有：
1 两阶段提交
2 三阶段提交
3 TCC
4 本地消息表
5 最大努力通知
6 saga

11. 阐述分表之后跨节点Join关联问题 ？

  正确回答通过率：41.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

在单库未拆分表之前，我们如果要使用join关联多张表操作的话，简直so easy啦。但是分库分表之后，两张表可能都不在同一个数据库中了，那么如何跨库join操作呢？

跨库Join的几种解决思路：
1.字段冗余：把需要关联的字段放入主表中，避免关联操作；比如订单表保存了卖家ID（sellerId），你把卖家名字sellerName也保存到订单表，这就不用去关联卖家表了。这是一种空间换时间的思想。
2.全局表：比如系统中所有模块都可能会依赖到的一些基础表（即全局表），在每个数据库中均保存一份。
3.数据抽象同步：比如A库中的a表和B库中的b表有关联，可以定时将指定的表做同步，将数据汇合聚集，生成新的表。一般可以借助ETL工具。
4.应用层代码组装：分开多次查询，调用不同模块服务，获取到数据后，代码层进行字段计算拼装。

12. 分库分表之后order by,group by等聚合函数处理方案 ？

 正确回答通过率：68.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

跨节点的count,order by,group by以及聚合函数等问题，都是一类的问题，它们一般都需要基于全部数据集合进行计算。可以分别在各个节点上得到结果后，再在应用程序端进行合并。

13. 简述分库分表后的分页问的处理方案 ？

  正确回答通过率：46.0%

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

方案1（全局视野法）：在各个数据库节点查到对应结果后，在代码端汇聚再分页。这样优点是业务无损，精准返回所需数据；缺点则是会返回过多数据，增大网络传输，也会造成空查，
比如分库分表前，你是根据创建时间排序，然后获取第2页数据。如果你是分了两个库，那你就可以每个库都根据时间排序，然后都返回2页数据，然后把两个数据库查询回来的数据汇总，再根据创建时间进行内存排序，最后再取第2页的数据。

方案2（业务折衷法-禁止跳页查询）：这种方案需要业务妥协一下，只有上一页和下一页，不允许跳页查询了。
这种方案，查询第一页时，是跟全局视野法一样的。但是下一页时，需要把当前最大的创建时间传过来，然后每个节点，都查询大于创建时间的一页数据，接着汇总，内存排序返回。

14. 如何生成全局唯一的分布式ID ？

  正确回答通过率：39.0%

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

全局的 unique ID 要满足以下需求:

保证生成的 ID 全局唯一
今后数据在多个 Shards 之间迁移不会受到 ID 生成方式的限制
生成的 ID 中最好能带上时间信息, 例如 ID 的前 k 位是 Timestamp, 这样能够直接通过对 ID 的前 k 位的排序来对数据按时间排序
生成的 ID 最好不大于 64 bits
生成 ID 的速度有要求. 例如, 在一个高吞吐量的场景中, 需要每秒生成几万个 ID (Twitter 最新的峰值到达了 143,199 Tweets/s, 也就是 10万+/秒)整个服务最好没有单点

那么如何实现全局唯一id呢？有以下几种方案。​

（1）方案一：独立数据库自增id
这个方案就是说你的系统每次要生成一个id，都是往一个独立库的一个独立表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个id。拿到这个id之后再往对应的分库分表里去写入。
比如说你有一个auto_id库，里面就一个表，叫做auto_id表，有一个id是自增长的。
那么你每次要获取一个全局唯一id，直接往这个表里插入一条记录，获取一个全局唯一id即可，然后这个全局唯一id就可以插入订单的分库分表中。
这个方案的好处就是方便简单，谁都会用。缺点就是单库生成自增id，要是高并发的话，就会有瓶颈的，因为auto_id库要是承载个每秒几万并发，肯定是不现实的了。

（2）方案二：uuid
这个每个人都应该知道吧，就是用UUID生成一个全局唯一的id。
好处就是每个系统本地生成，不要基于数据库来了
不好之处就是，uuid太长了，作为主键性能太差了，不适合用于主键。
如果你是要随机生成个什么文件名了，编号之类的，你可以用uuid，但是作为主键是不能用uuid的。

（3）方案三：获取系统当前时间
这个方案的意思就是获取当前时间作为全局唯一的id。
但是问题是，并发很高的时候，比如一秒并发几千，会有重复的情况，这个是肯定不合适的。
一般如果用这个方案，是将当前时间跟很多其他的业务字段拼接起来，作为一个id，如果业务上你觉得可以接受，那么也是可以的。
你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号，比如说订单编号：时间戳 + 用户id + 业务含义编码。

（4）方案四：snowflake算法的思想分析
snowflake算法，是twitter开源的分布式id生成算法。
其核心思想就是：使用一个64 bit的long型的数字作为全局唯一id，这64个bit中，其中1个bit是不用的，然后用其中的41 bit作为毫秒数，用10 bit作为工作机器id，12 bit作为序列号。

15. 列举目前主流的分库分表中间件 ？

 正确回答通过率：76.0%

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

Sharding-JDBC
cobar
Mycat
Atlas
TDDL（淘宝）
vitess