数据库优化上来就分库分表？面试官：您根本不懂底层原理

目录

数据库优化上来就分库分表？面试官：您根本不懂底层原理

---

常常面试会碰到，面试官询问数据库优化方面的问题。很多伙伴上来就是分库分表操作，听起来有道理，可您实操尝试过吗，有针对分类各种场景情况吗？本文主要分析数据库分库分表会有哪些问题阐述。

一. 数据库分库分表

分库

分库讲白了就是比如现在你有一个数据库服务器，数据库中有两张表分别是用户表和订单表。如果要分库的话现在你需要买两台机子，搞两个数据库分别放在两台机子上，并且一个数据库放用户表，一个数据库放订单表

 

这样存储压力就分担到两个服务器上了，但是会带来新的问题，所以东西变复杂了都会有新的问题产生。

1、联表查询问题 也就是join了，之前在一个数据库里面可以用上join用一条sql语句就可以联表查询得到想要的结果，但是现在分为多个数据库了，所以join用不上了。就比如现在要查注册时间在2019年之后用户的订单信息，你就需要先去数据库A中用户表查询注册在2019年之后的信息，然后得到用户id,再拿这些id去数据库B订单表中查找订单信息，然后再拼接这些信息返回。所以等于得多写一些代码了。

2、事务问题 搞数据库基本上都离不开事务，但是现在不同的数据库事务就不是以前那个简单的本地事务了，而是分布式事务了，而引入分布式事务也提高了系统的复杂性，并且有些效率不高还会影响性能例如Mysql XA。还有基于消息中间件实现分布式事务的等等这里不展开讲述。

分表

我们已经做了分库了，但是现在情况是我们的表里面的数据太多了，就一不小心你的公司的产品火了，像抖音这种，所有用户如果就存在一张表里吃不消，所以这时候得分表。分别又分垂直分表和水平分表。

垂直分表

垂直分表的意思形象点就像坐标轴的y轴，把x轴切成了两半，对应到我们的表就是比如我们表有10列，现在一刀切下去，分成了两张表，其中一张表3列，另一张表7列。

这个一刀切下去让两个表分别有几列不是固定的，垂直分表适合表中存在不常用并且占用了大量空间的表拆分出去。

就拿头条的用户信息，比如用户表只有用户id、昵称、手机号、个人简介这4个字段。但是手机号和个人简介这种信息就属于不太常用的，占用的空间也不小，个人简介有些人写了一坨。所以就把手机号和个人简介这两列拆分出去。

那垂直分表影响就是之前只要一个查询的，现在需要两次查询才能拿到分表之前的完整用户表信息。

水平分表

水平分表的意思形象点就像坐标轴的x轴，把y轴切成了两半(当然不仅限于切一刀，可以切好几份)。也拿用户表来说比如现在用户表有5000万行数据，我们切5刀，分成5个表，每个表1000万行数据。

水平分表就适合用户表行数很多的情况下，一般单表行数超过5000万就得分表，如果单表的数据比较复杂那可能2000万甚至1000万就得分了，这个得看实际情况有些表很简单可能一亿行都不用分。所以当一个表行数超过千万级别的时候关注一下，如果没有性能问题就可以再等等看，不要急着分表，因为分表会是带来很多问题。

水平分表的问题比垂直分表就更烦了。

要考虑怎么切，讲的高级点就叫路由

1、按id也就是范围路由，比如id 值1999万的放一张表，1000万1999放一张表，一次类推。这个得试的，因为范围分的大了，可能性能还有问题，范围分的小了。。那表不得多死。

这种分法的好处就是容易切啊，简单粗暴，以后新增的数据分表都不会影响到之前的数据，之前的数据都不需要移动。

2、哈希路由 就是取几列哈希一下看看数据哪个库，比如拿id来做哈希，1500取余8等于4，所以这条记录就放在user_4这个表中，2011取余8等于3，所以这条记录就放在user_3中。这种分法好处就是分的很均匀，基本上每个表的数据都差不多，但是以后新增数据又得分表了咋办，以前的数据都得动，比较烦！

3、搞一张表来存储路由关系 还是拿用户表来说，就是弄一个路由表，里面存userId和表编号，表示这个userId是这张user表的的。这种方式也简单，之后又要分表了之后改改路由表，迁移一部分数据。但是这种方法导致每次查询都得查两次，并且如果路由表太大了，那路由表又成为瓶颈了！

再说说查询时候的问题。

比如你要查注册时间最早的前100名用户，这就等于你得在水平分的每一张表都order by 一下注册时间并且取100个，然后再把每个表的100个结果对比一下得到最终的结果。首先操作变麻烦了，以前一个order by就搞定的事情现在变的复杂了，而且还得考虑一个因素就是时间的问题，如果你拆成了20个表，那你得执行20个order by，如果是串行执行的话，这个时间开销也是个问题！

分库分表的实现

具体实现也分为程序代码封装、数据库中间件封装。实现难度会比读写分离更大，至于两种封装的比较在讲读写分离时候已经说了，这里不再赘述。

总结

说了这么多好像分库分表一点都不好啊，没错会引入很多问题，所以在架构设计要遵循演化原则，任何东西都不是一蹴而就的，在不同场景适配不同的架构，架构只有合适的，没有一个架构可以适配任何场景。

在软件中简单够用就是好的，技术没有贵贱，不是用了分布式就牛逼，越复杂的系统维护的成本和难度越高，出现问题的几率越大。这种架构的演化往往都是被用户所驱动的，可以说是"不得已而为之"。

基本上单机数据库可以支撑10万用户量级别。所以一般情况下像数据库吃不消就升级硬件，优化数据库配置、优化代码、引入redis等。只有在真的不行了才上这些更复杂的东西。

二. 数据库分库分表事务解决方案

随着时间和业务的发展，数据库中表的数据量会越来越大，相应地，数据操作，增删改查的开销也会越来越大。因此，把其中一些大表进行拆分到多个数据库中的多张表中。
另一方面，在分库分表以后还需要保证分库分表的和主库的事务一致性。

1.需要解决问题

1.1 原有事务

由于分库分表之后，新表在另外一个数据库中，如何保证主库和分库的事务性是必须要解决的问题。

解决办法：通过在主库中创建一个流水表，把操作数据库的逻辑映射为一条流水记录。当整个大事务执行完毕后（流水被插入到流水表）,然后通过其他方式来执行这段流水，保证最终一致性。

1.2 流水

所谓流水，可以理解为一条事务消息

上面通过在数据库中创建一张流水表，使用一条流水记录代表一个业务处理逻辑，因此，一个流水一定是能最终正确执行的.因此，当把一段业务代码提取流水中必须要考虑到:

1. 流水延迟处理性。流水不是实时处理的，而是用过流水执行器来异步执行的。因此，如果在原有逻辑中，需要特别注意后续流程对该流水是不是有实时依赖性（例如后续业务逻辑中会使用流水结果来做一些计算等）。
2. 流水处理无序性。保证即使后生成的流水先执行，也不能出现问题。
3. 流水最终成功性。对每条插入的流水，该条流水一定要保证能执行成功

因此，提取流水的时候:

1. 流水处理越简单越好
2. 流失处理依赖越少越好
3. 提取的流水在该业务逻辑中无实时性依赖

1.3 流水处理器

流水处理器即要保证流水处理尽可能处理快，又能保证流水最终能执行成功。

设想一个场景：当出现某一条流水处理失败，如果流失执行器要等当前流水执行成功才继续往后执行，那么会影响后续流水的执行，更严重的是一直卡在当条记录，导致整个系统出现问题

因此，流水执行器中设置2个任务：

1. 第一个任务,流水处理任务，已最快的速度执行流水，如果流水处理失败了，也不影响后面流水处理
2. 第二个任务,流水校验任务，这个任务就是顺序检查流水记录，保证所有流水都执行成功，如果失败，进行重试，多次重试失败以后发出告警以让人工介入处理。

1.4 流水处理完成

因为流水表是放在原数据库中，而流水处理完成后是操作分库，如果分库操作完成去更新老表流水消息，那么又是夸库事务，如何保证流水状态的更新和分库也是在一个事务的？

解决办法是：在分库中创建一个流水表，当流失处理完成以后，不是去更新老表状态，而是插入分库流水表中、

这样做的好处：

1. 一般会对流水做唯一索引，那么如果流水重复多次执行的时候，插入分库流水表的时候肯定由于唯一索引检测不通过，整个事务就会回滚（当然也可以在处理流水事前应该再做一下幂等性判断）
2. 这样通过判断主库流水是否在分库中就能判断一条流水是否执行完毕

 

2、流水处理器基本框架

流水处理器其实不包含任何业务相关的处理逻辑，核心功能就是：

1. 通知业务接入方何时处理什么样的流水
2. 检验流水执行的成功

注：流水执行器并不知道该流水表示什么逻辑，具体需要业务系统去识别后去执行相对应业务逻辑。

2.1 流水执行任务

流水处理调度任务就是通过扫描待处理的流水，然后通知业务系统该执行哪一条流水。

示意图如下：

2.2 流水校验任务

流水校验任务就是要比较主库和分库中的流水记录，对执行未成功的流水通知业务系统进行重新处理，如果多次重试失败则发出告警。

流程示意图：

 3、为什么不用事务消息

由于是既有项目进行改造（本人从事互联网金融，所以是绝对不容忍有任何消息丢失或者消息处理失败)，不使用事务消息有1个原因

1. 需要额外引入消息队列，增加系统的复杂度，而且也需要额外的逻辑保证和消息队列通讯失败的时候处理
2. 其实1不算是主要原因，而是因为事务消息需要手动的commit和rollback（使用数据库不需要），那么问题来了，spring中事务是有传递性的，那我们事务消息何时提交又是个大问题，例如 A.a()本来就是一个事务， 但是另外一个事务B.b()中又调用了A.a() 那事务消息提交是放在A.a()还是B.b()中呢？

 

架构师需要具备业务抽象分析、架构设计、架构选型、容量规划、代码落地、架构治理等能力。这些能力中，最核心的能力是架构设计和架构选型。具体来讲，架构设计分为服务架构设计和存储架构设计，服务架构设计是选用微服务架构还是云原生架构？存储架构设计是选择RDBMS数据库、NoSQL数据库、还是NewSQL数据库？

参阅：https://www.cnblogs.com/lizo/p/8035036.html