为什么MySQL InnoDB的MVCC能解决幻读_深度解析多版本并发控制原理-mysql教程-PHP中文网

MVCC本身不解决幻读，仅保证快照读下两次查询行数一致；真正阻止幻读的是Next-Key Lock，它通过记录锁+间隙锁锁定值区间，阻塞符合条件的新插入。

为什么mysql innodb的mvcc能解决幻读_深度解析多版本并发控制原理

MVCC本身不解决幻读，只解决快照读下的“看起来像幻读”的现象

很多人误以为 MVCC 直接“解决了幻读”，其实不是。MySQL 官方定义的幻读是：同一事务中，两次相同条件的 SELECT 返回行数不同。而 MVCC 仅保证你在 SELECT（无锁、快照读）时看到的是事务启动时刻的一致性视图——它让你“看不见”其他事务新插入的行，所以两次 SELECT 行数一样。但这只是“视觉上没幻读”，不是真正阻止了插入。

关键点在于：MVCC 对 INSERT、UPDATE、DELETE 或带锁的 SELECT ... FOR UPDATE 完全不设防。这些操作走的是“当前读”，绕过 MVCC 快照，直接访问最新版本并加锁。

MVCC 只作用于普通 SELECT（即快照读），不干预写入路径
只要另一个事务在你事务执行期间 INSERT 并 COMMIT 了一条满足你查询条件的新记录，你的下一次“当前读”就会立刻看到它
如果你用的是 READ COMMITTED 隔离级别，每次快照读都生成新 ReadView，连“视觉上”的一致性都保不住——更易出现行数变化

真正拦住幻读的是 Next-Key Lock，不是 MVCC

在 REPEATABLE READ 级别下，InnoDB 对范围查询（如 WHERE id > 10）自动使用 Next-Key Lock：它 = Record Lock（锁住命中的索引记录） + Gap Lock（锁住记录之间的间隙）。这个组合锁住的是“值区间”，不是单点。

比如你执行 SELECT * FROM t WHERE age > 25 FOR UPDATE，InnoDB 不只锁住现有 age > 25 的行，还会锁住所有可能插入 age > 25 新记录的间隙（例如 (25, +∞)）。此时另一个事务尝试 INSERT INTO t VALUES (..., 28) 就会被阻塞，直到你事务结束。

没有索引？那会退化为表级锁（或全表扫描+大量间隙锁），性能极差
SELECT ... LOCK IN SHARE MODE 同样触发 Next-Key Lock，不只是 FOR UPDATE
唯一索引等值查询（WHERE id = 100）只用 Record Lock，不加 Gap Lock —— 此时仍可能发生幻读（比如插入 id = 100 但其他字段不同的重复行，若无唯一约束）

快照读 vs 当前读混用，才是幻读“复现”的典型场景

最常让人困惑的幻读案例，往往源于在一个事务里交替使用两种读法：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

事务 A 先执行 SELECT * FROM t WHERE score > 80（快照读，看到 3 行）→ 事务 B 插入 score = 85 的新行并提交 → 事务 A 再执行 UPDATE t SET bonus = 100 WHERE score > 80（这是当前读！会扫描最新数据，并更新包括 B 插入的那行）→ 事务 A 最后 SELECT * FROM t WHERE score > 80（又是快照读，但这次 ReadView 是事务开始时生成的，仍看不到 B 的行）→ 表面看“更新了 4 行但只查出 3 行”，就以为幻读发生了。