背景

在司机数据库中，有一张用于存储司机车型的表，暂且称之为表t。该表结构如下所示：

MySQL

[comp_epower]> show create table t \G; *************************** 1. row *************************** Table:

Create Table:

CREATE TABLE `t` (

`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',

`full_station_id` varchar(64) COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT '司机唯一Id',

`platform` int(4) NOT NULL DEFAULT '-1' COMMENT '车型id',

`create_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '时间',

PRIMARY KEY (`id`) USING BTREE,

KEY `idx_full_station_id` (`full_station_id`) USING BTREE )

ENGINE=InnoDB AUTO_INCREMENT=145612 DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='桩站上线渠道'

这张表的业务场景：以full_station_id为'test'来举例(full_station_id为的唯一Id)，如果在平板(车型号1)、小面(2)、金杯(3)，则在该表中会有如下三条记录：

MySQL [comp_epower]> select * from t where full_station_id = 'test';

发现问题

由于司机车型C端列表页的检索需求，DB中车型相关的信息需要同步到ES中，这其中就包括车型信息。由于历史原因，“同步”这个动作发生在业务流程中，即在B端管理平台上编辑司机车型信息时，后端服务器更新完DB需要检索出车型完整信息发送到MQ，再清洗数据到ES。数据同步到ES中后，每条车型信息中都存在一个platform的List，存储所有的渠道号用于C端检索。

以上述full_station_id为'test'的车型为例，ES中就可能有如下的一条数据：

{    // ... 省略其他字段    "full_station_id": "test",

"platform": [1, 2, 3]    // ... 省略其他字段 }

近期偶然发现，ES中platform列表中存在重复的渠道号。即DB中的数据是[1, 2, 3]三条记录，在es中变成了[1, 2, 3, 1, 2, 3]

定位问题

虽然初看起来好像并不影响检索，但是作为一个具有技术洁癖的程序猿来讲，错误一旦发现就必须解决。随后在日志检索平台上搜索该站最近一次的变更记录，成功定位到在16日该充车型在B端有编辑记录，而且是连续两次提交。查看源码后发现，这个B端的更新流程被包裹在一个长事务中，在此次事务中有多次RPC请求。这里简单介绍下编辑车型的流程：

开启事务

• 做一些车型相关的其他DB操作

• 删除该车型的全部已上线渠道记录，再将B端上传的渠道列表保存到库中

• 一堆RPC操作

• 从DB检索车型的已上线渠道记录，再结合其他一些车型的信息组成宽表发送给ES

• 提交事务

前面提到这次异常更新有两次连续的长事务，因此在机器上通过trace检索到全部日志，根据不同事件发生的时间点，还原两次编辑发生的完整历程。因为问题主要是渠道重复，因此主要将目光集中在渠道相关的几次操作，时间线如下：

通过日志还看出，在这两次事务开始之前，库中full_station_id为'test'的车型已经有[1, 2, 3]三条渠道记录。

那么开始在本地的mysql服务器上还原两次事务流程(本地mysql版本5.7.31-log，隔离级别可重复读)：

(1)建表、初始化数据

(2)开始按照上述两个事务的执行过程，还原现场

如上图所示。但是奇怪，上图中第9步按照当时事发现场日志来看应该是查询出来6条记录才对！

看到这里的小伙伴可以停下来想想上面的还原步骤哪里出了差错(在编辑车型流程里有线索)

回过头来仔细看了下编辑车型的流程以及日志的输出时间线，发现在对渠道进行DB操作之前，还进行了其他一些DB操作，而且在事务一提交之前，事务二已经完成了部分DB操作。回想到innodb事务开启的时机，我在本地还原的时候，右边事务二其实是在7这个位置才开启的(innodb事务不是在begin处开启，而是在第一次真正的db操作时开启)，也就是左边事务一在时刻6提交之后开启的。而实际上因为该长事务在渠道相关DB操作之前，已经做了其他的DB操作，所以这里梳理的流程图缺少了及其重要的一步：在事务一commit之前，将事务二开启起来。

重新梳理流程图

流程图V2中，事务二在t2时刻使用begin语句声明事务的开始，并在t3时刻事务一提交之前，完成了一次查询(随便什么)，开启了事务。那么此时事务二就是在事务一未提交之前开启的。

再次在本地mysql上按照时间线还原现场

可以看到第9步检索出了6条数据，成功还原！

真相只有一个

简单介绍下MVCC的原理

每个事务开启时，都会被分配到一个全局唯一且递增的事务id，即trx_id，当每次事务对某些数据行进行修改时，都会将事务自身的trx_id记录在数据行的隐藏列上。在事务开启的那一刻，MVCC机制会为事务生成一个当前mysql服务器上所有事务的快照。这个快照是按照如下方式实现的：

• 将当前服务端活跃的全部事务id记录在set中

• 当前活跃的事务最小id记为min_trx_id

• 当前活跃的事务最大id记为max_trx_id

• 当进行一次普通查询的时候，根据数据行上的trx_id进行判断。

  trx_id < min_trx_id，该行是在当前事务开启前就提交的，对当前事务可见。

  trx_id > max_trx_id，该行是在当前事务开启后开启的，对当前事务不可以。

  (但是trx_id > max_trx_id，并且max_trx_id比trx_id先提交，也是对当前事务可见的。事务对数据做修改时会发起一致性读，即强制读取最新的记录)

• min_trx_id <= trx_id <= max_trx_id，该行处在最大最小事务id中间，则判断是否为set中的活跃事务的修改。若是，则不可见；若不是，则说明当前事务开启时已经提交，则可见。

如何理解？

那既然 trx_id 这行数据，在快照最大最小事物中间了。那就肯定是最大最小中间的事物去修改的吧。会存在【若不是】的情况吗

就是在最大最小中间的某个事物，可能在拍照的时候，就已经提交了。这种就可以理解为在最小之前开启的，所以可见。

换个角度看，其实就是看这行数据是在拍照之前提交的，就可见。拍照之后(还未提交、就还在set中)就不可见(对前两条的补充)

对于隔离级别为可重复读而言，这个快照是在事务开启时生成的；对于读已提交，是在每次进行快照读的时刻生成的。

为行文方便，再次将上述流程梳理如下：

• 【1】[事务一]：begin;

• 【2】[事务一]：delete from t where full_station_id = 'test';

• 【3】[事务一]：insert into t(full_station_id, platform) values('test', 1), ('test', 2), ('test', 3);

• 【4】[事务一]：select * from t where full_station_id = 'test'

• 【5】[事务二]：begin;

• 【6】[事务二]：select * from t where full_station_id = 'test'

• 【7】[事务一]：commit;

• 【8】[事务二]：delete from t where full_station_id = 'test';

• 【9】[事务二]：insert into t(full_station_id, platform) values('test', 1), ('test', 2), ('test', 3);

• 【10】[事务二]：select * from t where full_station_id = 'test'

• 【11】[事务二]：commit

【1】首先，在两次事务开始之前，表里fullStationId为'test'的渠道记录有三条，如下所示：(这里的trx_id用来记录最后一次更新该列的事务Id，delete_mask用作删除标记，这两列都是innodb数据行上的隐藏列)

【2】事务一开启，此时事务一的活跃事务集合为【2】，即只有自身。进行删除操作，此时针对【1】中的三条数据会做如下几条操作：(省略无关操作)

• 将delete_mask设置为1(标记删除)

• 将trx_id设置为2

• 生成undo log，内容为将delete_mask改回0，trx_id改回1

此时这三条记录状态如下图所示：

这里的示意图可能与实际情况有所偏差，具体实现情况查看mysql相关文档。

【3】事务一插入三条记录。(注意后续示意图中没有画insert相关的undolog，只要清楚新insert数据的undo就是该行数据不存在即可)

【4】事务一查询fullStationId为'test'的记录，将六条数据分为上下两组，流程如下：

• 上面三条数据trx_id为2，为自身删除，因此不可见。

• 下面三条数据trx_id为2，为自身插入，可见。放入结果集中返回。

因此本次查询看到的是下面三条记录。

【5】事务二声明begin;

【6】事务二做了一次select操作，此时事务二真正开启，MVCC机制开始工作，因为事务一此刻还没提交，所以事务一的修改对事务二是不可见的。

假设事务二的trx_id为3，则在事务二开启一刻生成的活跃事务集合为【2,3】

那么事务二在进行普通的select查询时，实际上是做了一次快照读。将表里当前存在的数据分为两组，上面三条和下面三条。

• 上面三条的trx_id为2，在活跃事务集合里，不可见。沿着undo链表往前回溯到上一个trx_id为1的版本。trx_id=1

• 下面三条的trx_id为2，在活跃事务集合里，不可见。回溯undolog，发现是insert类型undolog，停止回溯，结束查询。

所以此时事务二进行快照读，只读到了上面三条记录。

【7】事务一提交

【8】事务二执行delete操作。此时删除的是上面三条，还是下面三条？

答案是下面三条，原因是一致性读。对于delete而言，首先肯定要在表里检索到符合条件的记录，那么在可重复读级别下，事务对数据做修改时会发起一致性读，即强制读取最新的记录，不管MVCC。所以该次操作实际上删除的是事务一插入的三条记录，流程与步骤【2】相仿，之后数据表状态如下图所示：(一致性读时对于上面三条记录而言，已经是被已提交事务删除了，因此事务二本次delete操作不对它们做操作)

【9】事务二插入三条记录，之后数据表状态如下：

【10】事务二进行一次快照读，此时MVCC机制产生作用。将九条数据分为上中下三组，则流程如下：

• 上面三组trx_id为2，在活跃事务集合中，因此不可见。沿着undo链表回溯到trx_id为1的记录，可见，放入结果集。

问：trx_id为2，在活跃事务集合中？如何判断是否在活跃事物中？

答：事物二开启的时候，快照了set

• 中间三组trx_id为3，是当前事务的trx_id。因为delete_mask为1，表明当前事务做了删除，不可见。

• 下面三组trx_id为3，是当前事务的trx_id，因此可见，放入结果集。

所以本次快照读结果为6条，分别为事务一和二开启前的三条数据，加上事务二插入的三条数据。

【11】事务二提交。

后记

分析流程到这里就结束了，感谢在排查问题过程中跟我一起讨论问题的同学们，能遇到这种mysql实践的场景也不多，所以也感谢写出这个长事务的朋友:)。其实对于这个case每步操作的加锁情况也值得深入分析，包括实际上undolog是使用数据行上的roll_pointer指针来引用的等等这些原理，碍于篇幅都没有过多提及。

最终我也是在代码中将最后一个对于渠道的select查询加上了for update语句，强制进行一致性读，暂时可以解决这个问题(对于去除长事务是一个稍微大点的改造，暂时没有做)。不知道各位小伙伴有没有更好的办法，欢迎在评论区留言，文章中的错误提前感谢各位指正。

其他：长事物拆分、异步