MySQL中MVCC与锁机制的协同运作原理及幻读规避方式咨询

这个问题问得很到位，刚好戳中了InnoDB并发控制里MVCC和锁机制协同的关键点，我来一步步给你理清楚：

先明确核心前提：RR级别下幻读的彻底解决需要MVCC + 间隙锁 #

首先纠正一个常见误区：MVCC单独在可重复读（RR）级别下，只能解决「快照读场景」的幻读，无法解决「当前读场景」的幻读。InnoDB之所以能在RR级别彻底规避幻读，是把MVCC和间隙锁（Gap Lock）的能力结合起来，针对不同的读场景分工协作。

MVCC的无锁特性与它能解决的幻读 #

你说的没错，MVCC是基于undo log（回滚日志）构建的版本链机制，全程不需要加锁，核心逻辑是：

• 每个事务启动时，会生成一个一致性快照，后续的快照读（普通SELECT语句）都会基于这个快照返回数据，完全看不到其他事务在快照生成后新增、修改的行。
• 比如事务T1启动后执行普通SELECT，此时事务T2插入了新行，T1再次执行普通SELECT还是看不到这个新行，这就是MVCC解决了快照读下的幻读。

但这里有个边界：如果T1执行的是当前读（比如SELECT ... FOR UPDATE、UPDATE、DELETE），MVCC的快照机制就不生效了，当前读会直接读取最新的数据，这时候如果没有锁的限制，T2插入的新行就会被T1读到，幻读就出现了。

间隙锁的作用：堵住当前读的幻读漏洞 #

这时候就需要间隙锁（Gap Lock）登场了，它是InnoDB在当前读场景下触发的锁机制：

• 当事务执行当前读操作（比如SELECT ... FOR UPDATE）时，InnoDB会对符合条件的行加行锁，同时对这些行之间的「间隙」（比如表中有id=1、id=3的行，间隙就是(1,3)、(3,+∞)）加间隙锁。
• 间隙锁的核心作用是阻止其他事务在这个间隙内插入新行，这样就能保证当前读的事务后续再执行当前读时，不会出现新的行，彻底堵住幻读的漏洞。

MVCC与锁机制的协同逻辑 #

两者不是互斥关系，而是针对不同场景分工：

• 快照读场景：完全由MVCC接管，无锁，其他事务的写操作（更新、插入、删除）正常执行，只是在undo log中追加新的版本链，各事务基于自己的快照读取数据，互不干扰。
• 当前读场景：由锁机制（行锁+间隙锁，即Next-Key Lock）保证数据的一致性，同时MVCC会配合锁机制，在锁释放后，让其他事务能通过undo log读取到正确的版本。

针对你具体问题的解答 #

1. MVCC会在事务T1中添加间隙锁吗？
   不会，间隙锁是当前读操作触发的锁机制，MVCC本身不涉及加锁。只有当T1执行当前读（比如SELECT ... FOR UPDATE）时，InnoDB的锁机制才会自动添加间隙锁。

2. 当事务T2在间隙锁范围内执行更新/插入时，是追加undo log还是被阻塞？
   会被阻塞，直到T1提交或回滚释放间隙锁。因为间隙锁的设计目的就是阻止其他事务修改或插入间隙内的数据，保证当前读事务的一致性。只有当T1释放锁后，T2的操作才能继续执行，此时才会生成对应的undo log版本。

举个直观的例子：

假设表t有id=1、id=3两行数据，事务T1在RR级别执行SELECT * FROM t WHERE id>1 FOR UPDATE

• InnoDB会对id=3加行锁，同时对间隙(1,3)、(3,+∞)加间隙锁
• 此时事务T2尝试插入id=2的行，会被直接阻塞，直到T1提交/回滚
• 如果T1只是执行普通SELECT（快照读），T2插入id=2的行不会被阻塞，但T1后续的普通SELECT还是看不到id=2，这就是MVCC的作用

内容的提问来源于stack exchange，提问作者ruokuanwu