MySQL MVCC核心机制详解：从版本链到ReadView的隔离级别实践-代码聚汇网

MySQL MVCC核心机制详解：从版本链到ReadView的隔离级别实践

要上进的柯同学·2026-09-04·阅读 22 GEO检测（免费）

MySQLMVCCInnoDB

|难度：普通|阅读约 41 分钟

前几天线上有个业务反馈，一条很普通的UPDATE语句偶发卡顿，最后报锁等待超时。排查下来不是慢SQL，也不是索引失效，而是两个事务同时更新同一行，写锁互相排队。这里就牵出一个几乎所有MySQL开发者都会遇到、但真正讲透的人不多的核心机制：MVCC多版本并发控制。

MVCC（Multi-Version Concurrency Control，多版本并发控制）是InnoDB实现隔离级别的底层基础，也是面试题里出现频率最高的知识点之一。很多人能背出“读不阻塞写、写不阻塞读”这句话，但问到ReadView是怎么生成的、为什么RR（可重复读）和RC（读已提交）表现不一样、MVCC和锁到底是什么关系的时候，就开始含糊。这篇文章不打算只讲概念，我会从一条数据行的物理结构开始，一步步拆解版本链、ReadView的判定逻辑、和next-key lock的配合方式，再结合线上排查和面试里常见的追问，把整条链路疏通。

1. 先搞清MVCC解决的问题：读写互杀不是数据库该有的样子

1.1 锁方案的两难：安全但串行化太慢

并发控制最朴素的办法就是加锁。一个事务读某行时加共享锁（S锁），写某行时加排他锁（X锁），锁之间互不兼容就排队等。这个方案能保证数据安全，但代价非常大。

锁类型	S锁（共享锁）	X锁（排他锁）
S锁	兼容	冲突
X锁	冲突	冲突

看上面这张表就能明白：只要有一个事务在写某条记录，所有想读这条记录的事务都会卡住。反过来，大量读事务持锁时，写事务也进不来。

在典型的互联网业务里，读多写少是常态，读请求比例经常占到90%以上。如果一个写操作会把大量读请求全部堵死，数据库的并发能力会直线下降。这是锁方案天然存在的两难：锁用少了，脏读、不可重复读、幻读都会冒出来；锁用多了，吞吐量难看，用户体验更差。

1.2 MVCC的思路：每行数据留多个版本

MVCC换了一个角度：既然“读”和“写”之间互相阻塞是主要矛盾，那能不能让读操作不拿锁，直接去读一个符合当前事务隔离级别要求的“历史版本”？

这就是“多版本”的含义。InnoDB在更新一条记录时，并不会把老数据直接抹掉，而是把更新前的旧值记录在undo log里，聚簇索引上的记录本身变成一个“新版本”，旧版本通过回滚指针串成链。某个事务读取时，通过ReadView判断：哪个版本对这个事务是可见的，就读哪个版本。写事务要修改记录时只需要跟正在写同一行的其他写事务竞争，读事务完全不用参与锁竞争。

所以MVCC并不是替代所有锁，它真正解决的是“读写并发”问题，让读不阻塞写、写不阻塞读。两个事务同时写同一条记录时，依然要靠X锁互斥。

1.3 快照读与当前读：两条完全不同的读取路径

很多初学者搞不清MVCC的使用边界，根源在于没区分快照读（consistent read）和当前读（locking read）。

快照读：普通的SELECT语句，在RC和RR隔离级别下不加任何锁，直接通过ReadView读取可见版本，所以执行效率很高，也不需要等待其他事务释放锁。
当前读：SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE，以及UPDATE、DELETE、INSERT操作，都必须读记录的最新已提交版本，然后对记录加锁。

当前读不能走MVCC的历史版本，因为写操作必须基于最新数据做修改。比如两个事务同时把账户余额从100改成200，如果各改各的历史版本，最后必然丢更新。所以当前读之间必须用锁互斥。

理解这两条路径非常重要。后面说“MVCC解决了幻读”时，一定得限定在快照读场景；当前读场景下幻读要靠间隙锁解决，否则就会得出错误结论。

1.4 为什么MVCC主要服务于RC和RR两个隔离级别

MySQL InnoDB的隔离级别有四种，但MVCC并不是在四个级别下都在工作：

READ UNCOMMITTED（读未提交）：直接读最新版本，连已提交都不用等，压根不需要ReadView。
READ COMMITTED（读已提交）：每条快照读SQL生成一个新的ReadView，是MVCC的典型应用场景。
REPEATABLE READ（可重复读）：整个事务只在第一条快照读时生成一次ReadView，后续全部复用，也是MVCC的典型应用场景，还是InnoDB默认隔离级别。
SERIALIZABLE（串行化）：所有读操作都会被强制转成当前读，通过锁来串行执行，MVCC基本退场。

所以平时聊MVCC，默认就是在RC和RR两个隔离级别下面聊。脱离隔离级别去讨论MVCC，很多结论都是不成立的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据行上的三个“隐形标签”：隐藏列与undo log版本链

2.1 每行自带的档案：DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID

MVCC看起来玄乎，最终还是要落到物理存储上。InnoDB的聚簇索引记录和普通表记录不一样，除了用户定义的数据列之外，每行还隐藏着几个数据库自己用的列：

DB_ROW_ID：6字节，行ID。如果表没有主键也没有非空唯一索引，InnoDB会用它来生成聚簇索引，一般不需要关注。
DB_TRX_ID：6字节，记录最后一次修改（INSERT、UPDATE、DELETE）这行数据的事务ID。事务ID是MySQL内部按顺序分配的数字，值越大表示事务开始得越晚。
DB_ROLL_PTR：7字节，回滚指针。它指向这条记录在undo log里对应的历史版本，负责把一系列版本串成一个单向链表。

这三个隐藏列平时用普通SELECT查不出来，但它们就是MVCC判断版本可见性的核心依据。如果脑海里能浮现每条记录上都挂着这三个字段，理解后面内容会顺畅很多。

2.2 undo log如何把历史版本串成链

拿更新操作举例。假设有一张user表，id=1的这行数据name='Tom'。执行一条UPDATE语句把name改成'Jack'时，InnoDB内部做了两件事：

先把修改前的整行旧数据（name='Tom'及当时的隐藏列信息）写进undo log；
再把这行数据的name更新为'Jack'，同时把DB_TRX_ID改成当前事务ID，把DB_ROLL_PTR指向刚写入的undo log。

如果接下来又一个事务把name改成'Lucy'，同样会先把'Jack'版本的旧值写进undo log，再更新当前行，把回滚指针指向新写入的undo记录。

最终形成的效果是：聚簇索引当前行保存的是最新版本，它通过DB_ROLL_PTR指向第二个旧版本，第二个旧版本再通过自己的回滚信息指向第一个旧版本，整个串成一条“版本链”。最新版本在链头，越往链尾走版本越老。旧版本记录里同样也会补全自己的历史字段信息，这样每次往前回溯才能持续走下去。

有人会问，MVCC是不是在磁盘上把所有历史版本都复制了一份？严格说不是物理上的整表多拷贝，而是借助undo log记录了行的变更历史。每次更新都会产生一条undo记录，链上的每个版本占用一小块undo空间，并且会有后台线程在合适的时机清理不需要的历史版本。这个机制比“每次修改都拷贝一张全表快照”要轻量得多。

2.3 UPDATE和DELETE在版本链上留下的不同痕迹

INSERT比较简单，插入的新行自带一个版本，指向一个insert undo，事务提交后这个undo通常可以被很快清理，因为MVCC判断可见性时不需要读它。

UPDATE和DELETE则不一样。UPDATE会产生update undo，里面保存被修改前的旧版本数据，MVCC事务在回溯时需要读取这些旧版本，所以不能事务一提交就清掉。

DELETE更特殊一点。从用户视角看，DELETE就是删除一行；但从InnoDB视角看，DELETE本质上是一次特殊的UPDATE。它把这行记录的delete flag标记为已删除，同时生成一条undo log，保留被删除前的整行数据，并且更新DB_ROLL_PTR。这就是为什么在一个长事务里删除大量数据后，undo空间可能不降反涨，因为那些被标记删除的旧版本还在版本链上服役，不能立刻物理清理。

2.4 purge线程：历史版本由谁清扫

版本链上保留这么多历史版本，不可能永远堆积。InnoDB有一个后台purge线程，负责清理那些“没有任何活跃事务需要读取”的旧版本数据。

判断标准是当前系统中所有ReadView都已经不关心那些旧版本了。简单说，如果一个很早开启的事务一直不提交，它的ReadView还停留在过去某个时间点，那这个时间点之后产生的所有历史版本它都有可能需要读，于是purge线程只能看着这些数据干瞪眼。长事务跑得越久，版本链堆积越长，undo表空间占用也会持续增长。

这也是为什么我一直建议线上不要开大事务、长事务，不只是锁的问题，MVCC机制本身也会因为长事务的ReadView长期存活而拖住大量历史数据无法清理。

2.5 能不能直接看到隐藏列的值

有时候想验证某个版本的DB_TRX_ID是多少，但SELECT并不能直接输出隐藏列。想快速验证可以借助实验：开两个会话，事务A更新某行后不提交，事务B去执行普通SELECT，你会发现B读到的是旧值。这已经间接证明B的ReadView判定过程中，A生成的新版本被屏蔽了。

如果想更直观地看到事务ID，可以用ibd2sdi或解析物理文件的方式，但日常排查中一般用不到。真正线上排查时，我们更关心的是“哪个事务还活着”，而不是某个隐藏列的具体数值。

3. ReadView可见性判定：MVCC的“决策中心”

3.1 ReadView的四个核心字段

版本链已经建好了，但一个事务发起快照读时，到底该读版本链上哪一个？这个决策工作由ReadView来完成。ReadView可以理解成“我发起读的这个瞬间，数据库里活跃事务的一张快照”，它由四个核心部分组成：

m_ids：生成ReadView时，当前系统中所有活跃的读写事务ID列表。
min_trx_id：m_ids中的最小值，也就是活跃事务里最早开启的那个事务ID。
max_trx_id：系统为下一个将要分配的事务ID预留的值，不是m_ids的最大值，理解成“生成ReadView时系统发号器已经发到的位置之后再+1”会更准确。
creator_trx_id：生成这个ReadView的事务自己的ID。

为什么max_trx_id不是m_ids的最大值？因为m_ids只包含当前还活跃的事务，而max_trx_id会包含那些在ReadView生成之后才开启的事务。把这两个概念混淆，很多人后面读判定算法会绕晕。

3.2 版本可见性判定算法拆解

拿到版本链上某个版本的DB_TRX_ID后，InnoDB按下面的顺序判断：

如果DB_TRX_ID等于creator_trx_id：说明这个版本是当前事务自己修改的，自己改的数据自己当然能看到，判定为可见。
如果DB_TRX_ID小于min_trx_id：说明生成这个版本的事务，在ReadView创建之前就已经提交了，判定为可见。
如果DB_TRX_ID大于等于max_trx_id：说明这个版本是由ReadView生成之后才开启的事务修改的，对当前事务不可见。
如果DB_TRX_ID在min_trx_id和max_trx_id之间，则该判断它是否在m_ids列表中：
- 在m_ids中，说明事务在ReadView生成那一刻仍然活跃、还没提交，不可见；
- 不在m_ids中，说明事务在ReadView生成前已经提交，可见。

如果当前版本不可见，怎么办？沿着这条记录的回滚指针DB_ROLL_PTR找到上一个历史版本，把那个版本的DB_TRX_ID再拿来做一轮同样的判断。一直重复，直到找到一个可见版本，或者走到版本链的尽头。如果找不到任何可见版本，就说明这行数据对当前事务来说相当于不存在。

整个判定逻辑其实就是在回答一句话：这个版本的修改者，在我开始读的那个瞬间，到底“提交了没有”。

3.3 用一组SQL模拟完整的判定过程

光看理论不够，我们模拟一个经典场景。表t_user中有id=1这一行，初始name='Tom'，事务ID为99的事务插入并提交了这行数据。

事务B开启，事务ID为100，执行UPDATE把name改成'Jack'，但不提交。
此时事务C开启并执行普通SELECT，事务ID为105。

C执行快照读时生成ReadView，m_ids中包含B的100，min_trx_id=100，max_trx_id=106，creator_trx_id=105。

C读到当前行，看到的name='Jack'。检查它的DB_TRX_ID=100：

100不等于creator_trx_id 105；
100不小于min_trx_id 100；
100小于max_trx_id 106；
100在m_ids列表中，说明事务B还没有提交，当前这个'Jack'版本不可见。

于是C沿着DB_ROLL_PTR找到上一个版本name='Tom'。这个旧版本的DB_TRX_ID=99：

99不等于105；
99小于min_trx_id 100，说明这个版本在ReadView创建之前已经提交，可见。

事务C最终读到name='Tom'，而不是被事务B刚修改但尚未提交的'Jack'。整个流程可以自己开两个MySQL会话亲自跑一遍，看到的结果会和这里一致。

3.4 为什么自己事务更新过的记录必须直接可见

看判定算法的第一条会觉得理所应当，其实背后有一个很重要的设计考量：事务内先UPDATE再SELECT时，如果ReadView不认自己产生的版本，事务会看不到自己刚做的修改。

我举个例子：业务代码在一个事务里执行UPDATE user SET status=1 WHERE id=1，然后紧接着同事务又执行SELECT status FROM user WHERE id=1，期望拿到1。如果InnoDB把自己事务产生的版本也判定为不可见，这个SELECT就会沿着版本链找到更早的旧版本，返回status=0。那才叫真正的诡异行为。

所以creator_trx_id的可见性判断永远放在第一位。同理，INSERT产生的新记录，如果DB_TRX_ID是自己的也直接可见。这就保证了事务内部“先写后读”的语义是自洽的。

4. RC与RR里MVCC表现完全不同：一条SQL在不同隔离级别下的差异

4.1 Read Committed：每条快照读都生成新的ReadView

RC隔离级别下，事务内每执行一条普通SELECT，都会生成一个全新的ReadView。这意味着前面事务开启时生成的ReadView不会带到下一条SQL，下一条SQL的m_ids会重新采集当前活跃事务列表。

带来的效果就是：其他事务提交后，当前事务再执行下一条SELECT，新ReadView里已经不包括那个已提交事务的ID，于是能看到别人提交的最新数据。这正是RC名字的由来——每次读到的都是已提交的最新数据。

换句话讲，RC下的一致性读只能保证“我读到的是某时刻已经提交的数据”，不能保证事务内多次读到的结果一致，所以RC天然存在不可重复读问题。

4.2 Repeatable Read：整个事务复用一个ReadView

RR隔离级别下，InnoDB在事务执行第一条普通SELECT时生成ReadView，然后这个事务后续所有快照读都复用同一个ReadView，m_ids、min_trx_id、max_trx_id全部不再变化。

既然ReadView固定了，那么其他事务后续提交与否，在当前事务看来都不影响可见性判断。事务B改名'Jack'并提交后，事务A再查一次，ReadView里的m_ids依然记录着B的事务ID，于是A仍然看不到'Jack'版本，还是会拿到'Tom'。这就是可重复读的实现原理——它靠的不是把数据复制一份，而是把判定数据的“参照系”固定在了第一次读的时刻。

经常有人问RR的一致性快照是不是类似“读已提交但时间戳冻结”，我觉得可以这样理解：数据库没有冻结任何真实数据，真实数据该更新还是更新，只是当前事务的ReadView把自己的视线锁死在某个历史时刻。

4.3 一个经典案例看出两者的差异

造一张工资表，初始小明工资1000。事务A开始，SQL1查工资得到1000。事务B执行UPDATE把小明工资改成1500并提交。事务A再执行SQL2查工资：

RC模式下，SQL2生成新ReadView，B已经不是活跃事务，所以A看到1500。
RR模式下，SQL2复用SQL1时的ReadView，B仍在m_ids里，所以A还是看到1000。

这个例子值得反复跑几遍。跑通之后，对“读已提交”和“可重复读”这两个隔离级别的理解会完全不一样，不再只是背概念，而是真正看到了底层机制的差异。

4.4 如何确认当前事务的隔离级别

MySQL 5.7及以前用这个命令查看：

sql复制SELECT @@tx_isolation;

MySQL 8.0之后变量名改成了transaction_isolation：

sql复制SELECT @@transaction_isolation;
SHOW VARIABLES LIKE 'transaction_isolation';

也可以在会话级别临时修改：

sql复制SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

注意RR才是InnoDB默认级别，很多公司在binlog为ROW格式的前提下主动改成RC，目的是减少间隙锁带来的锁竞争。具体用哪个级别取决于业务需求，但如果应用程序依赖可重复读语义，贸然改成RC会出问题。

5. 幻读的“漏网之鱼”：MVCC和next-key lock如何配合

5.1 快照读场景：ReadView把幻读挡在门外

先明确什么是幻读：一个事务内执行两次相同的查询，第二次读到了第一次没看到的新插入记录，也就是结果集的行数变了。

在RR下，事务第一条普通SELECT生成ReadView后，其他事务插入并提交的新行，DB_TRX_ID对当前ReadView来说属于“未来事务”，所以当前事务的快照读不会读到这些新插入行。在快照读这个层面，MVCC已经解决了幻读。

所以网上有些文章说“MVCC解决不了幻读，要靠间隙锁”，严谨的表述应该是：MVCC解决了RR下快照读的幻读问题，但没有解决当前读的幻读问题，当前读必须依赖锁机制。

5.2 当前读场景：MVCC管不到的地方

事务T1执行SELECT ... FOR UPDATE或UPDATE时，它需要看到最新已提交版本并加锁，不能读历史版本，否则就可能基于旧数据做修改。

看一个典型的幻读时序：

事务T1执行SELECT * FROM orders WHERE id > 100 FOR UPDATE，当前没有任何id大于100的记录。
事务T2执行INSERT INTO orders VALUES (200)，如果数据库没有阻止，T2提交成功。
事务T1再次执行同样的SELECT ... FOR UPDATE，此时它做的是当前读，会看到刚插入的id=200这条记录。两次结果行数不一致，幻读出现了。

如果不加额外措施，MVCC的ReadView在这里救不了忙，因为当前读必须读最新版本。

5.3 InnoDB怎样用next-key lock焊死间隙

为了解决当前读下的幻读，InnoDB在RR级别引入了Next-Key Lock，它本质上是**Record Lock（记录锁）和Gap Lock（间隙锁）**的合并体。

记录锁只锁住精确匹配的某条索引记录。
间隙锁锁住某个索引记录之间的区间，禁止其他事务在这个区间内插入新记录。
Next-Key Lock则锁住“从某条记录到下一个键值之间的左开右闭区间”，既锁记录也锁间隙。

当T1执行id > 100的当前读时，InnoDB会锁住满足条件的索引记录，同时锁住这些记录之间的间隙，以及边界后面的间隙。T2往这个范围里插入id=200时，会和间隙锁冲突，插入操作必须等待，直到T1提交或回滚。这样就保证了T1当前读的两次结果一致。

注意一个细节：如果条件是唯一索引的等值查询且记录已存在，InnoDB会优化成只加记录锁不加间隙锁；如果等值查询没命中记录，依然会加间隙锁。做锁分析时一定要结合具体索引和SQL条件，不能一刀切。

5.4 用两个会话直接验证幻读被锁拦截

打开两个MySQL会话，把隔离级别设为RR：

sql复制-- 会话A
START TRANSACTION;
SELECT * FROM orders WHERE id >= 10 AND id <= 15 FOR UPDATE;

此时会话A锁住了order表id在10到15范围内已有的索引记录以及该范围内的间隙。再到会话B执行：

sql复制-- 会话B
INSERT INTO orders(id, order_no) VALUES (12, 'NO20240015');

这条INSERT会被阻塞，等会话A提交或回滚后才能继续。通过SHOW ENGINE INNODB STATUS可以看到类似的锁等待信息，里面会有gap lock相关描述。

这个实验能直观感受到当前读的幻读是怎么被锁挡住的，也很适合拿去面试中讲清楚MVCC与next-key lock的分工。

6. 顺着索引看版本可见性：普通索引查询为何常常要回表“验明正身”

6.1 二级索引记录上没有事务ID，版本怎么判

到这里为止，我们讨论的可见性都基于聚簇索引，因为DB_TRX_ID、DB_ROLL_PTR都保存在聚簇索引的记录里。但实际查询大量走的是二级索引，二级索引的叶子节点只保存索引列和主键值，根本不含事务ID。

那么问题来了：一条记录在二级索引里存在，但它对应的可见版本可能是旧的，也可能是被删除标记的，二级索引本身没法直接判断。最稳妥的办法就是根据索引里的主键值回表，到聚簇索引上找出完整记录，再看DB_TRX_ID完成可见性判定。

这也是“回表”的原因之一。很多人以为回表只是因为SELECT的列没被索引覆盖，其实在MVCC场景里，只要二级索引页无法被快速判定为全部可见，存储引擎就需要回表确认主键版本的可见性，才能决定这条索引记录能不能返回给上层。

6.2 页级PAGE_MAX_TRX_ID：先做一次粗筛

如果每条二级索引记录都回表验证，效率太低。InnoDB在二级索引页的页头保存了一个PAGE_MAX_TRX_ID字段，记录的是“最后修改该二级索引页的事务ID”。

判断时有个快速路径：如果当前ReadView的min_trx_id大于PAGE_MAX_TRX_ID，说明修改过这个页面的所有事务，在当前ReadView生成之前都已经提交了，整个页面的记录对当前事务都可见，可以直接使用二级索引记录，不需要逐条回表裁决。

如果min_trx_id并不大于PAGE_MAX_TRX_ID，说明页面上可能混有当前ReadView不可见的版本，这时才需要回表，用聚簇索引上的DB_TRX_ID执行完整判定。

这个设计很像缓存里的布隆过滤器：大部分情况下用开销极低的粗筛直接通过，少部分情况再走精确比对，用少量回表代价换掉了绝大多数无谓回表。

6.3 回表后的“二次审判”流程

当二级索引页不能通过粗筛时，InnoDB会取出二级索引记录里带的主键值，回表到聚簇索引，读取对应主键行的完整记录，然后拿到DB_TRX_ID和回滚指针，执行前面讲过的ReadView判定算法。

如果主键行当前版本不可见，还要沿着DB_ROLL_PTR继续访问undo log里的历史版本，直到找到一个对当前ReadView可见的版本为止。因此回表不只是“根据主键取数据”这么简单，在版本可见性不满足时，它还会触发历史版本探测。

这也能解释一种现象：为什么活跃事务较多或者存在长事务时，一些原本执行计划不错的SQL会突然变慢。因为被长事务保存的旧版本阻碍了purge，版本链变长，回表后在版本链上回溯的代价变大。不要只看执行计划里有没有Using index，还要看事务并发状态。

6.4 覆盖索引没法完全绕开版本判断

很多人以为只要让查询走覆盖索引，就不需要回表。这个说法在大方向上没错，但要注意：覆盖索引避免的是“为了读取被查询列而回表”，版本可见性判断是另一条逻辑链路。

如果二级索引页的PAGE_MAX_TRX_ID粗筛无法让当前ReadView免检，那么即使SELECT的列都被索引覆盖了，存储引擎仍然需要根据索引记录回表查看主键行的DB_TRX_ID，确认这条二级索引记录是否可见，哪怕它最终不需要读取额外列。

MySQL 5.6引入的索引条件下推（Index Condition Pushdown，ICP）可以在存储引擎层先用索引列条件过滤掉一部分二级索引记录，减少回表量。但ICP过滤完成后，对于保留下来的记录，版本可见性判断的逻辑并没有变化。理解了这层关系，你对执行计划里出现的Using index condition就不会再误读为“完全不回表”。

7. 面试题与线上问题：聊点能“抄作业”的

7.1 高频面试追问和回答思路

MVCC相关面试题翻来覆去就是那几类，但每一类都可以往深了追：

问：简单讲一下什么是MVCC？
参考思路：MVCC是InnoDB通过保存数据行的多个历史版本，配合ReadView来实现并发控制的一种机制。它让普通SELECT走快照读不加锁，写操作和读操作互不阻塞，主要服务于RC和RR两个隔离级别。

问：RC和RR在MVCC实现上有什么区别？
参考思路：RC每次快照读都生成新的ReadView，所以能读到别的事务最新提交的数据；RR只在第一条快照读时生成ReadView并复用，所以同一个事务里多次读结果一致。

问：RR为什么能解决快照读下的幻读，当前读又靠什么解决幻读？
参考思路：RR的快照读通过固定ReadView，让新插入但未提交或事务开启后提交的记录对当前事务不可见；当前读需要读最新版本，靠Next-Key Lock锁定记录和间隙来阻止其他事务插入新行。

问：一条UPDATE语句会不会触发MVCC的版本链读取？
参考思路：UPDATE是当前读，直接加锁读取最新版本并修改，不使用ReadView做历史版本可见性判断，但它会生成新的版本写进版本链，供后续其他事务的快照读使用。

问法可以千变万化，核心只要抓住“快照读走ReadView、当前读走锁”以及“ReadView时机决定隔离级别表现”这两条主线，就不容易答乱。

7.2 线上长事务为什么会让undo膨胀

MVCC与线上性能关系最密切的一个场景就是长事务。一个事务开启后长时间不提交，它的ReadView不会被释放，导致事务开启之后产生的所有旧版本数据都不能被purge线程清理。如果这个期间业务一直在更新数据，undo log就会持续堆积，回滚段占用不断增长。

我遇到过一起案例：一个定时任务在同一个数据库事务里调用了外部HTTP接口，接口超时重试了10分钟，事务就一直挂着，期间业务表大量更新，结果undo表空间迅速增长，磁盘告警。最后杀掉这个事务后，purge才逐步把历史版本清理掉，但表空间回收还需要额外处理。

为了避免这类问题，最直接的手段是缩短事务边界。数据库事务里尽量只放数据库操作，外部调用、缓存更新、消息发送这些容易阻塞的I/O操作都应该放在事务外面。同时建立长事务监控，超过阈值就告警。

7.3 用SQL定位长事务和锁等待

线上排查时，information_schema下面有两张表非常实用。

先看当前有哪些事务在运行：

sql复制SELECT * FROM information_schema.innodb_trx\G

重点看trx_started字段，判断事务已经开了多久；trx_query字段能看到事务当前正在执行的SQL。一旦发现事务长时间不结束，就要找到对应的应用连接。

再看锁等待关系：

sql复制SELECT * FROM sys.innodb_lock_waits\G

sys schema的这张表会自动关联出谁在等锁、谁持有了锁、等待多久。正常诊断步骤是：先通过innodb_lock_waits找到锁源事务，再去innodb_trx里看这个事务的执行时间和状态，最后回到应用侧定位为什么事务没结束。

7.4 新手最容易踩的三个认知误区

第一个误区：**认为MVCC会保存一整套完整的行快照副本。**实际上InnoDB保存的是变更前的undo日志，通过版本链逻辑构造出历史版本，不是把每行数据完整复制出N份存在表空间里。

第二个误区：**认为RR隔离级别下，其他事务修改了数据，当前事务一定读不到。**准确说法是当前事务的快照读读不到，但当前读（比如SELECT ... FOR UPDATE、UPDATE）依然会读取最新已提交版本。事务里先执行当前读再去快照读，和先做快照读再当前读，结果可能不一样，这点在业务设计时要注意。

第三个误区：**认为MVCC可以替代锁机制。**MVCC解决的是读写并发冲突，写写冲突依然要靠X锁互斥。InnoDB的并发控制是MVCC和锁一起工作的结果，少掉任何一环都会出问题。顺便多说一句，MVCC是InnoDB引擎的特性，MyISAM这类不支持事务的引擎没有这套机制。

我自己复盘MVCC时最大的心得是：不要把ReadView记成一段死代码，而是把它想成“我点开页面那一刻，正在处理订单的收银台列表”。列表里的人是还没办完业务的，他们刚碰过的数据我不能拿；列表外的人已经办完走人了，他们留下的数据我可以放心用。有了这个画面，事务ID的每一次比较都有了实际意义。

最后给想彻底搞懂MVCC的人一个建议：别只看文章，动手开两个MySQL会话，把RC和RR分别跑一遍我前面模拟的更新和查询实验，观察结果差异，再结合`SHOW ENGINE INNODB