Mybatis-Plus“读-批量写-读”数据不一致的问题分享

 背景

技术选型与版本： SpringBoot 2.7.6、Mybatis-Plus 3.1.0

技术名词： 快照读、ReadView、Undo log、SqlSession、一级缓存

在日常开发过程中，时常会遇到一个如下场景：

1. 根据条件x，读取表A，得到多行数据；
2. 遍历读取到的数据，对条件x以外的字段进行修改，并进行保存；（重点）
3. 修改后，调用通用方法，传入条件x，重新读取表A的数据，并进行MQ广播；

流程如下图

业务代码MybatisMQ开启事务第一次查询S1条件x查询返回查询结果R1更新修改查询结果R1批量更新更新成功第二次查询S2条件x查询返回查询结果R2发送MQ结果R2发送MQ提交事务业务代码MybatisMQ

以上业务流程，是一个很普通的流程，一眼看去没什么问题，以下是我们期望的流程结果：

• 第一次条件x查询，得到结果R1；
• 修改R1后执行更新；
• 第二次条件x查询，得到结果R2为更新后在当前事务中的最新数据；

但是在我们实际测试中，却发现，对于相同的条件x的前后两次查询S1和S2，得到的居然是一样的结果数据。若按照以上的业务流程，第二次查询后发送MQ，如果R2不是最新值，那么可能导致MQ消费者数据不一致的情况。

下面来看一下伪代码演示。

示例演示

以下伪代码中，为了方便演示，不进行MQ操作，直接使用打印日志代替

可以看到，在执行Mybatis-Plus提供的批量更新方法updateBatchById后，重新读取数据，居然还是更新前的数据，那这到底是怎么回事呢，我们往下分析与追踪。

分析与追踪

在这个案例中，只有查询-更新-查询的代码，数据库使用的是MySQL，ORM框架使用的是Mybatis-Plus，所以可以从以下两方面进行排查

1. MySQL事务；
2. MyBatis-Plus；

mysql事务

知识点A：在MySQL中，Innodb基于MVCC思想实现快照读。核心思想是利用事务的ReadView与undo log版本链进行匹配，从而判断当前事务能读取到哪个版本的数据。即，在Innodb的默认隔离级别为可重复读时，对于同一事务下，写操作的结果对下一个读操作是可见的。

详见大佬博客：blog.csdn.net/SIESTA030/a…

回到上面的案例代码，可见，当前代码的“读-写-读”操作，是被包含在同一个事务中，事务管理完全交给Spring事务管理器，且并未对事务传播行为进行控制，所以按照MySQL的知识点，可以确定，第二次“读”操