MySQL幻读解决方案：RR隔离级别MVCC与间隙锁原理详解

MySQL的RR隔离级别分场景解决幻读：快照读靠MVCC隐藏新插入行，当前读靠next-key lock阻塞插入；但混合使用两类读仍可能导致逻辑幻读。

RR隔离级别下幻读是否被解决

关于MySQL的RR隔离级别是否解决了幻读，答案并非简单的“是”或“否”，而是一个“分场景”的精细处理。具体来说，对于普通的SELECT（快照读），它依靠MVCC机制让你“看不见”新插入的行；而对于那些需要加锁的读操作，比如带FOR UPDATE的SELECT，或者UPDATE、DELETE这类DML操作（统称当前读），则依靠next-key lock这把锁，直接物理上阻塞其他事务的插入行为。所以，笼统地断言“RR解决了幻读”并不准确，关键在于你用的是哪种读法。两种机制并存，目标却高度一致：确保在同一个事务内，无论你怎么查，结果集都不会凭空多出或少掉行。

快照读为什么看不到新插入的行

快照读的“隐身”能力，并非来自锁，而是源于一套精巧的版本可见性判断规则，也就是MVCC。每个事务启动时，都会生成一个自己的ReadView，你可以把它理解成事务观察数据世界的一个“快照视角”。这个视角里包含了up_limit_id（活跃事务的最小ID）、low_limit_id（下一个将要分配的事务ID）等关键信息。对于任何新插入的行，其DB_TRX_ID（创建该行的事务ID）必然大于当前事务的up_limit_id。因此，它不满足“行的创建版本 ≤ 当前事务版本，且删除版本为空或 > 当前事务版本”这条核心可见性规则，自然就被过滤掉了。

这就解释了那个常见的“错误”现象：事务A里执行两次SELECT * FROM users WHERE age >= 25，事务B中途插入一条age=28的记录并提交，结果事务A第二次查询依然看不到这条新记录。这可不是什么bug，完全是MVCC按规则办事的结果。

• 需要明确的是，只有基于主键或唯一索引的等值查询，间隙锁才有可能退化为纯记录锁。一旦涉及范围查询，间隙锁或临键锁就一定会被触发。
• ReadView在事务中第一次执行快照读时生成，后续所有的快照读都会复用这个视图，并不会因为其他事务提交了而更新。
• 如果事务A先执行了UPDATE操作，再执行SELECT，那么这次SELECT会被InnoDB升级为当前读。此时，MVCC机制失效，查询将转而走锁机制。

当前读如何用next-key lock阻塞插入

当SQL语句带有明确的加锁意图时，比如SELECT ... FOR UPDATE，或者本身就是UPDATE、DELETE这类操作，InnoDB就会亮出它的锁机制武器——next-key lock。这本质上是一个组合拳：记录锁（锁住索引记录本身）加上间隙锁（锁住记录之间的空隙）。举个例子，执行SELECT * FROM users WHERE id > 100 FOR UPDATE，它锁定的其实是索引中第一个id大于100的记录，以及这个记录左侧的间隙，形成一个左开右闭的区间，比如(100, 150]。这样一来，任何试图在这个区间内插入新记录（比如id=120）的事务，都会被直接阻塞住。

不过，这里有几个容易踩的坑：

• 如果WHERE条件没有用到索引，会导致全表扫描，进而可能对全表加上next-key lock，性能瞬间雪崩。
• 间隙锁之间是相互兼容的，但它们与INSERT操作天生互斥。这意味着，当多个事务并发尝试向同一个大致范围插入数据时，大家就得排队等待。
• 有一个参数叫innodb_locks_unsafe_for_binlog，如果将其设置为1，会全局禁用间隙锁。这虽然能提升一些并发度，但彻底破坏了RR隔离级别的语义，导致主从数据不一致的风险急剧增加，生产环境是绝对严禁开启的。

为什么RR不等于Serializable却宣称防幻读

这就引出了一个有趣的问题：既然RR隔离级别不等于最高级的Serializable（可串行化），为什么官方文档又宣称它能“防止幻读”呢？关键在于对“幻读”定义的理解差异。官方遵循的是SQL标准中的一种相对宽松的定义：它只要求在同一事务内，多次执行SELECT ... FOR UPDATE（当前读）时，结果集保持一致。而开发者通常理解的“幻读”——即两次普通SELECT（快照读）结果行数不同——在RR级别下确实有可能发生。只要事务里混合使用了快照读和当前读，这种“逻辑上的幻读”就不属于SQL标准定义的幻读范畴。

真正需要警惕的复杂情况，恰恰就出现在这种混合使用模式里。当同一个事务中既用快照读又用当前读时，ReadView的可见性规则和锁机制会交叉作用，行为变得难以预测。比如，先执行一个普通的SELECT（快照读），再执行一个SELECT ... FOR UPDATE（当前读）。后者除了加锁，会刷新之前生成的ReadView吗？答案是：不会。ReadView只在首次快照读时生成并固定。但是，当前读所加的锁范围可能会扩大，从而影响其他并发事务的插入操作。这种快照读的“静态视图”与当前读的“动态加锁”之间的隐式耦合，构成了RR隔离级别下最容易被忽略的灰度地带，也是许多并发问题潜伏的温床。