DB分库分表习题集

关注

原创最新推荐文章于 2026-04-10 10:05:38 发布 692 阅读 AI 写同款· GEO 优化 ›

实战解析：如何利用MDFEND与Weibo21数据集构建多领域假新闻检测系统本文实战解析了如何利用MDFEND模型与Weibo21数据集构建多领域假新闻检测系统。文章深入剖析了MDFEND的领域门控与专家混合机制，并提供了从数据预处理、模型理解到训练部署的完整指南，旨在解决通用模型在不同领域新闻检测中的性能衰减问题，提升检测的准确性与适应性。阅读详情

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作为序列号。