如何理解MySQL 8.0中MVCC机制解决幻读的原理-mysql教程-PHP中文网

mysql 8.0 innodb在rr级别下普通select（快照读）不会幻读，因复用固定readview；但若误触当前读（如for update、update等）或索引失效导致间隙锁失效，则仍会发生幻读。

如何理解mysql 8.0中mvcc机制解决幻读的原理

快照读不会产生幻读，但你写的SQL可能根本没走快照读

MySQL 8.0 的 InnoDB 在 REPEATABLE READ 隔离级别下，**普通 SELECT 确实不会出现幻读**——这不是宣传口径，而是 MVCC + 固定 ReadView 的必然结果。事务启动后第一次执行 SELECT 时生成的 ReadView 会复用到整个事务结束，所有后续快照读都基于同一份“快照”，新插入且已提交的行（其 DB_TRX_ID > ReadView.max_trx_id）直接不可见。

但问题常出在：你以为自己在做快照读，其实触发了当前读。以下情况会绕过 MVCC 快照，强制读最新版本并加锁：

SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE
UPDATE、DELETE 语句（哪怕 WHERE 条件没命中任何行）
对未命中索引的范围条件执行 SELECT（如 WHERE status = 'pending' 但 status 无索引）——此时会退化为全表扫描+每行当前读

一旦触发当前读，就进入 Next-Key Lock 范畴，而幻读是否发生，取决于锁能否覆盖插入点。

Next-Key Lock 不是万能的，间隙锁失效场景很常见

Next-Key Lock 是 Record Lock + Gap Lock 的组合，目标是封锁「索引记录之间的间隙」。但它只在**有可用索引**的前提下生效。如果你的查询条件无法利用索引（例如 WHERE name LIKE '%java%' 或 WHERE created_at > '2026-01-01' 但该字段没建索引），InnoDB 会放弃间隙锁，仅对实际扫描到的记录加行锁（Record Lock），此时其他事务就能在间隙中自由插入新行。

典型反例：

-- 假设 course_inventory 表只有主键 id，没有 course_name 索引
BEGIN;
SELECT * FROM course_inventory WHERE course_name = 'AI入门' FOR UPDATE; -- 全表扫描，只锁住匹配的行（可能一行不锁）
-- 此时事务B可成功 INSERT INTO course_inventory VALUES (100, 'AI入门', 5);

这个插入不会被阻塞，事务A第二次执行相同 SELECT ... FOR UPDATE 就会看到新行——幻读发生。

MySQL

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

下载

为什么“先查后插”会失败？不是解决了幻读吗

这是最容易混淆的点：MVCC 和 Next-Key Lock 解决的是「读一致性」和「写冲突控制」，**不保证业务逻辑原子性**。比如经典库存扣减场景：

BEGIN;
SELECT stock FROM course_inventory WHERE id = 1; -- 快照读，得到 stock=10
-- 事务B在此刻 INSERT 新记录或 UPDATE stock = 0（但没提交）
UPDATE course_inventory SET stock = stock - 1 WHERE id = 1; -- 当前读，检查最新值，加行锁
COMMIT;

这段代码看似安全，但若事务B在事务A的 SELECT 后、UPDATE 前插入了一条 id=1 的重复数据（违反主键约束），或更新了 stock 导致扣减后为负——这些都不是幻读，而是业务校验缺失。MVCC 不负责判断“stock - 1 >= 0”，它只确保你能读到一致的版本、写操作能安全加锁。

真正要堵住这类漏洞，得靠：

唯一索引/主键约束（防重复插入）
SELECT ... FOR UPDATE 替代普通 SELECT（让读也参与锁竞争）
应用层显式校验 + 数据库 CHECK 约束（MySQL 8.0.16+ 支持）

RR 级别下幻读仍存在的三个真实条件

官方文档说 RR “解决了幻读”，严格来说是指标准测试用例（如《ISO/IEC 9075》定义的简单范围查询）。但在工程实践中，只要满足以下任一条件，幻读就可能出现：

查询使用了 **非唯一二级索引 + OR / IN / 函数索引表达式**，导致优化器放弃使用间隙锁
事务中混用快照读和当前读：第一次 SELECT（快照读）没看到新行，第二次 SELECT ... FOR UPDATE（当前读）却锁到了新行
使用了 READ COMMITTED 隔离级别 —— 此时每次快照读都新建 ReadView，新提交的插入行在第二次查询时可见

最隐蔽的坑是：Spring 的 @Transactional(isolation = Isolation.REPEATABLE_READ) 只设置隔离级别，但 MyBatis 默认的 select 仍是快照读；一旦你在 service 方法里手动调用 update()，就自动触发当前读，前后读视图已不一致。