php master-slave 分库分表面试题目_「职场面试」数据库常见面试题 (二)-MySQL分库分表

在上期内容中，我们探讨了关于索引以及选择等数据库面试题目，不知大家的学习效果如何？本期，树懒君将带来关于分库分表领域的面试题目分享，这可是个颇具代表性的问题呢！

首先，我们需要明确分库与分表是两个不同的概念，切勿将它们混淆。有时候，我们只进行分库而不分表，亦或是只分表而不分库，这些情况都是可能出现的。现在，让我们直接进入正题，提出问题！

1.分区方案有哪些？

分区表是通过多个相互关联的底层表来构建的。这些底层表同样以句柄对象的形式存在，故而我们能够直接对各个分区进行访问。存储引擎在管理这些基础表时，与处理普通表的方式一致（所有基础表均需采用相同的存储引擎）。而分区表的索引，实际上就是各个基础表共享的索引。此方案有效地隐藏了用户细节，即便查询条件缺失，系统仍能正常运行。

MySQL的分区功能有哪些用途？有哪些不同的分区类型？为何众多互联网企业更倾向于自行进行数据库的拆分，即分库分表，而非采用分区策略？

众多资源受到个体局限，例如在连接数目和网络传输速率等方面。而在实际应用中，如何实现隔离，便成为了一个至关重要的考量因素。

5.为什么要分库分表？

从性能上看

随着数据存储库的规模持续扩大，查询操作每秒的请求数量不断提升，数据库进行读写操作所需的时间也随之增长。这种情况下，数据库的读写效率可能成为制约业务扩展的关键因素。因此，有必要对数据库的性能进行优化。本文将聚焦于探讨数据库层面的优化策略，而不会涉及缓存等应用层面的优化方法。

当数据库的查询每秒请求数量超出合理范围时，我们应考虑对数据库进行拆分，以通过分散存储的方式减轻单个数据库的连接负担。比如，若查询每秒请求数量为3500，而一个数据库能够承受的连接数为1000，那么我们可以将数据库拆分为4个，以此来分散查询带来的连接压力。

当单表数据量变得异常庞大，一旦数据量突破某个临界点，无论是进行数据检索还是更新操作，即便是在数据库层面通过索引优化等传统方法进行优化后，也可能遭遇性能瓶颈。这种情况下，数量的增加导致了质的转变。这时，我们需转变解决问题的思路。比如，从数据生成和处理的起点入手寻找解决方案。鉴于数据量庞大，我们应采取分而治之的策略，逐一解决，最终化为零。这种做法产生了分钟，依据既定规则将数据划分为若干个钟表单元，有效解决了钟表环境中访问性能的难题。

从可用性上看

一旦某个数据库遭遇故障，其内部数据极有可能全部丢失。尤其在当前云计算盛行的时代，众多数据库运行于虚拟机之上。一旦虚拟机或宿主机出现故障，将可能导致无法弥补的损失。鉴于此，我们除了采用传统的-Slave、-等部署方式外，还可以从数据分割的角度来寻求解决方案。

此处我们以数据库宕机为例：

当然，我们不可无度地拆分存储库，这种做法虽能通过牺牲存储资源来增强系统的性能与可用性，但资源终究是有限的。

6. 如何分库分表（分库？分表？还是既分库又分表？）

分库分表方案可以分为下面3种

分库分表

7. 如何对数据进行切分？

一般而言，划分方法主要分为垂直拆分和水平拆分两种，而在某些业务场景较为复杂的情况下，人们也会选择将这两种方式结合起来进行划分。

垂直拆分

在构建垂直分表时，我们通常会依据业务功能的运用频次，将那些使用率较高的字段汇集一处，形成核心的主表。与此同时，对于那些使用频率较低的内容，则会依据它们各自的业务特性进行归类，进而划分为若干个辅助的次级表。通常情况下，主表与次级表之间的关联模式是相互独立的，即一对一的关系。

水平拆分(数据分片)

单表容量若超500W，则宜考虑分级处理。若将一块手表复制成具有相同结构的另一块手表，并依照特定规则将数据分散存储于这些手表内，以确保手表容量适中，从而提升性能。当然，这些结构一致的手表可以集中存放在一个或多个数据库之中。

水平分割的几种方法：

分表