玩转MySQL：一站式解决分库分表后患问题方案

本文链接：https://blog.youkuaiyun.com/Java_LingFeng/article/details/128327652

引言

上篇有关分分库分表一文中已经将分库分表的方法论全面阐述清楚了，总体看下来用一个字形容，那就是爽！（手动狗头）尤其是分库分表技术能够让数据存储层真正成为三高架构，但前面爽是爽了，接着一起来看看分库分表后产生一系列的后患问题，注意我这里的用词，是一系列而不是几个，也就是分库分表虽然好，但你要解决的问题是海量的。

一、垂直分表后带来的隐患

垂直分表后当试图读取一条完整数据时，需要连接多个表来获取，对于这个问题只要在切分时，设置好映射的外键字段即可。当增、删、改数据时，往往需要同时操作多张表，并且要保证操作的原子性，也就是得手动开启事务来保证，否则会出现数据不一致的问题。

这里可以看到，垂直分表虽然会有后患问题，但带来的问题本质上也不算大问题，就是读写数据的操作会相对麻烦一些，下面来看看其他的分库分表方案，接下来是真正的重头戏。

二、水平分表后带来的问题

水平分表就是将一张大表的数据，按照一定的规则划分成不同的小表，当原本的一张表变为多张表时，虽然提升了性能，但问题随之也来了~

2.1、多表联查问题（Join）

之前在库中只存在一张表，所以非常轻松的就能进行联表查询获取数据，但是此时做了水平分表后，同一张业务的表存在多张小表，这时再去连表查询时具体该连接哪张呢？似乎这时问题就变的麻烦起来了，怎么办？解决方案如下：

①如果分表数量是固定的，直接对所有表进行连接查询，但这样性能开销较大，还不如不分表。
②如果不想用①，或分表数量会随时间不断变多，那就先根据分表规则，去确定要连接哪张表后再查询。
③如果每次连表查询只需要从中获取1~3个字段，就直接在另一张表中设计冗余字段，避免连表查询。

第一条好理解，第二条是啥意思呢？好比现在是按月份来分表，那在连表查询前，就先确定要连接哪几张月份的表，才能得到自己所需的数据，确定了之后再去查询对应表即可，这里该如何落地实现呢？大家别急，会在后续的《库内分表篇》去详细讲解。

2.2、增删改数据的问题

当想要增加、删除、修改一条数据时，因为存在多张表，所以又该去哪张表中操作呢？这里还是前面那个问题，只要在操作前确定好具体的表即可。但还有一种情况，就是批量变更数据时，也会存在问题，要批量修改的数据该具体操作哪几张分表呢？依旧需要先定位到具体分表才行。

2.3、聚合操作的问题

之前因为只有一张表，所以进行sum()、count()....、order by、gorup by....等各类聚合操作时，可以直接基于单表完成，但此刻似乎行不通了呀？对于这类聚合操作的解决方案如下：

①放入第三方中间件中，然后依赖于第三方中间件完成，如ES。
②定期跑脚本查询出一些常用的聚合数据，然后放入Redis缓存中，后续从Redis中获取。
③首先从所有表中统计出各自的数据，然后在Java中作聚合操作。

前面两种操作比较好理解，第三种方案是什么意思呢？比如count()函数，就是对所有表进行统计查询，最后在Java中求和，好比分组、排序等工作，先从所有表查询出符合条件的数据，然后在Java中通过Stream流进行处理。

上述这三种方案都是比较合理且常规的方案，最好是选择第一种，这也是一些大企业选用的方案。

到这里就大致聊清楚了单库中分表的一些主要问题，一般情况下库内无需做分表，只有一些特殊场景下需要做，具体的会在后续《库内分表篇》讲解，下面聊聊分库问题，分库带来的问题更多更复杂。

三、垂直分库后产生的问题

垂直分库是按照业务属性的不同，直接将一个综合大库拆分成多个功能单一的独享库，分库之后能够让性能提升N倍，但随之而来的是需要解决更多的问题，而且问题会比单库分表更复杂！

3.1、跨库Join问题

因为将不同业务的表拆分到了不同的库中，而往往有些情况下可能会需要其他业务的表数据，在单库时直接join连表查询相应字段数据即可，但此时已经将不同的业务表放到不同库了，这时咋办？跨库Join也不太现实呀，此时有如下几种解决方案：

①在不同的库需要数据的表中冗余字段，把常用的字段放到需要要数据的表中，避免跨库连表。
②选择同步数据，通过广播表/网络表/全局表将对应的表数据直接完全同步一份到相应库中。
③在设计库表拆分时创建ER绑定表，具备主外键的表放在一个库，保证数据落到同一数据库。
④Java系统中组装数据，通过调用对方服务接口的形式获取数据，然后在程序中组装后返回。

这四种方案都能够解决需要跨库Join的问题，但第二、三种方案提到了广播表/网络表/全局表、ER绑定表似乎之前没听说过对嘛？这其实是分库分表中的一些表名词，后续《分库分表实践篇》具体落地时会详细讲解。但往往垂直分库的场景中，第四种方案是最常用的，因为分库分表的项目中，Java业务系统那边也绝对采用了分布式架构，因此通过调用对端API接口来获取数据，是分布式系统最为常见的一种现象。

3.2、分布式事务问题

分布式事务应该是分布式系统中最核心的一个问题，这个问题绝对不能出现，一般都要求零容忍，也就是所有分布式系统都必须要解决分布式事务问题，否则就有可能造成数据不一致性。

在之前单机的MySQL中，数据库自身提供了完善的事务管理机制，通过begin、commit/rollback的命令可以灵活的控制事务的提交和回滚，在Spring要对一组SQL操作使用事务时，也只需在对应的业务方法上加一个@Transactional注解即可，但这种情况在分布式系统中就不行了。

为什么说MySQL的事务机制会在分布式系统下失效呢？因为InnoDB的事务机制是建立在Undo-log日志的基础上完成的，以前只有一个Undo-log日志，所以一个事务的所有变更前的数据，都可以记录在同一个Undo-log日志中，当需要回滚时就直接用Undo-log中的旧数据覆盖变更过的新数据即可。