java八股文面试[数据库]——分库分表

本是古典何须时尚 2024-03-05 01:41 131阅读 0赞

###### **什么是分库分表** ######

简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到**分散单台设备负载**的效果。

![image.png][]

*  ###### 分库分表解决的问题 ######
    
    分库分表的目的是为了解决由于**数据量过大**而导致数据库**性能降低**的问题，将原来单体服务的数据库进行拆分.将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库**性能**的目的。
 *  ###### 什么情况下需要分库分表 ######
    
     *  单机**存储容量**遇到瓶颈.
     *  **连接数**,**处理能力**达到上限.

> 注意:
> 
> 分库分表之前,要根据项目的实际情况 确定我们的数据量是不是够大,并发量是不是够大,来决定是否分库分表.
> 
> 数据量不够就不要分表,单表数据量超过1000万或100G的时候, 速度就会变慢(官方测试),

###### 分库分表包括： 垂直分库、垂直分表、水平分库、水平分表 四种方式。 ######

###### **垂直分库** ######

*  数据库中不同的表对应着不同的业务，垂直切分是指按照**业务的不同**将表进行分类,分布到不同的**数据库**上面
    
     *  将数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果
    
    ![image.png][image.png 1]

###### **垂直分表** ######

表中**字段太多**且**包含大字段**的时候，在查询时对数据库的IO、内存会受到影响，同时更新数据时，产生的**binlog文件会很大**，MySQL在主从同步时也会有延迟的风险

*  将一个表按照字段分成多表，每个表存储**其中一部分字段**。
 *  对职位表进行垂直拆分, 将职位基本信息放在一张表, 将职位描述信息存放在另一张表

![image.png][image.png 2]

*  垂直拆分带来的一些提升
    
     *  解决**业务层面的耦合**，业务清晰
     *  能对不同业务的数据进行**分级管理**、维护、监控、扩展等
     *  高并发场景下，垂直分库一定程度的提高**访问性能**
 *  垂直拆分没有彻底解决单表**数据量过大**的问题

###### **水平分库** ######

*  将单张表的数据切分到多个服务器上去，每个服务器**具有相应的库与表**，只是表中**数据集合不同**。 水平分库分表能够有效的缓解单机和单库的**性能瓶颈和压力**，突破**IO**、**连接数**、**硬件资源**等的瓶颈.
 *  简单讲就是根据表中的数据的**逻辑关系**，将同一个表中的数据按照**某种条件**拆分到多台数据库（主机）上面, 例如将订单表 按照id是奇数还是偶数, 分别存储在不同的库中。
    
    ![image.png][image.png 3]

###### **水平分表** ######

*  针对数据量**巨大的单张表**（比如订单表），按照规则把一张表的数据切分到多张表里面去。 但是这些表还是在同一个库中，所以**库级别**的数据库操作还是有IO瓶颈。
    
    ![image.png][image.png 4]
 *  总结
    
     *  **垂直分表**: 将一个表按照字段分成多表，每个表存储其中一部分字段。
     *  **垂直分库**: 根据表的**业务不同**,分别存放在不同的库中,这些库分别部署在不同的服务器.
     *  **水平分库**: 把一张表的数据按照一定规则,分配到**不同的数据库**,每一个库只有这张表的部分数据.
     *  **水平分表**: 把一张表的数据按照一定规则,分配到**同一个数据库的多张表中**,每个表只有这个表的部分数据.

###### 水平分库分表策略 ######

分库分表策略一般有几种，使用与不同的场景：

*  range范围
 *  hash取模
 *  range+hash取模混合

###### **1 range范围** ######

range，即范围策略划分表。比如我们可以将表的主键，按照从`0~1000万`的划分为一个表，`1000~2000万`划分到另外一个表。如下图：

![图片][9cff01e5961b9ed616665b62401f6b79.jpeg]

当然，有时候我们也可以按时间范围来划分，如不同年月的订单放到不同的表，它也是一种range的划分策略。

**这种方案的优点：**

*  这种方案**有利于扩容**，**不需要数据迁移**。假设数据量增加到5千万，我们只需要水平增加一张表就好啦，之前`0~4000万`的数据，不需要迁移。

**缺点：**

*  这种方案会有热点问题，因为订单id是一直在增大的，也就是说**最近一段时间**都是汇聚在一张表里面的。比如最近一个月的订单都在`1000万~2000`万之间，平时用户一般都查最近一个月的订单比较多，请求都打到`order_1`表啦，这就导致表的**数据热点**问题。

###### **2 hash取模** ######

hash取模策略：指定的路由key（一般是user\_id、订单id作为key）对分表总数进行取模，把数据分散到各个表中。

比如原始订单表信息，我们把它分成4张分表：

![图片][45c141e8a69b14e99d8c3ff1330b9015.jpeg]

*  比如id=1，对4取模，就会得到1，就把它放到第1张表，即`t_order_0`;
 *  id=3，对4取模，就会得到3，就把它放到第3张表，即`t_order_2`;

**这种方案的优点：**

*  hash取模的方式，不会存在明显的热点问题。

**缺点：**

*  如果一开始按照hash取模分成4个表了，未来某个时候，**表数据量又到瓶颈了**，**需要扩容**，这就比较棘手了。比如你从4张表，又扩容成`8`张表，那之前`id=5`的数据是在（`5%4=1`，即第一张表），现在应该放到（`5%8=5`，即第`5`张表），也就是说**历史数据要做迁移了**。

###### **3 range+hash取模混合** ######

既然range存在热点数据问题，hash取模扩容迁移数据比较困难，我们可以综合两种方案一起嘛，取之之长，弃之之短。

比较简单的做法就是，在拆分库的时候，我们可以先用**range范围**方案，比如订单id在04000万的区间，划分为订单库1，id在4000万8000万的数据，划分到订单库2,将来要扩容时，id在8000万~1.2亿的数据，划分到订单库3。然后订单库内，再用**hash取模**的策略，把不同订单划分到不同的表。

![图片][7978be36a806beedb36b36f949959c7a.jpeg]

###### **分库分表会导致哪些问题** ######

**分库分表之后，也会存在一些问题：**

*  事务问题
 *  跨库关联
 *  排序问题
 *  分页问题
 *  分布式ID

1 事务问题

分库分表后，假设两个表在**不同的数据库**，那么**本地事务**已经无效啦，需要使用**分布式事务**了。

2 跨库关联

跨节点Join的问题：解决这一问题可以分两次查询实现

3 排序问题

跨节点的count,order by,group by以及**聚合函数**等问题：可以分别在各个节点上得到结果后在应用程序端进行合并。

4 分页问题

*  方案1：在个节点查到对应结果后，在代码端**汇聚再分页**。
 *  方案2：把分页交给前端，前端传来pageSize和pageNo，在各个数据库节点都执行分页，然后汇聚总数量前端。这样缺点就是会造成空查，如果分页需要排序，也不好搞。

5 分布式ID

据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑**UUID**，或者使用**雪花算法**生成分布式ID。

###### **分库分表中间件** ######

**目前流行的分库分表中间件比较多：**

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

![图片][bcd2fcaeec3ec03c370f10f223e46199.jpeg]

知识来源：马士兵教育

[12张图把分库分表讲的明明白白！][12]

[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/22939b984e3340999b0a2baf925250f0.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/6984d1204b84462b9c6e5582851f053b.png
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/c1855498eeee4292ae134dc4f559637f.png
[image.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/8240ce81fe734881b6f0ac766e2f3b49.png
[image.png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/b77118cdd8b64e5fa1aaf3affeb5374d.png
[9cff01e5961b9ed616665b62401f6b79.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/fa4158cc639143ad9159dbef7c99accb.png
[45c141e8a69b14e99d8c3ff1330b9015.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/964f229a0e5e492f9307a74d3b2c2ef0.png
[7978be36a806beedb36b36f949959c7a.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/dee1a068d4cb46cfab0d15c273e526a1.png
[bcd2fcaeec3ec03c370f10f223e46199.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/05/372a36a7fdcf4b07b6739cb9ba7b1a93.png
[12]: https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247547792&idx=2&sn=91a10823ceab0cb9db26e22783343deb&chksm=fbb1b26eccc63b784879f90540c8ab1731e635b30e5f4fd41de67f87a4fe055473039206f09d&scene=27