MySQL在RC隔离级别下无法避免幻读，因其仅对命中行加行锁、不启用间隙锁，导致当前读（如SELECT ... FOR UPDATE）可读到其他事务新插入的符合查询条件的行；而快照读结果变化属不可重复读，非幻读。
MySQL在RC隔离级别下无法避免幻读，不是因为MVCC没起作用，而是因为MVCC只管“快照读”，而幻读只发生在“当前读”场景中——SELECT ... FOR UPDATE、UPDATE、DELETE这类操作根本不会用快照，而是直接查最新已提交版本。
RC下每次SELECT都新建ReadView，但仅限快照读
RC的隔离逻辑是：每次执行普通SELECT（无锁）前，都会生成一个新的ReadView，因此事务内两次快照读可能看到不同结果（比如第二次读到了其他事务刚COMMIT的新行）。但这不叫幻读，这叫“不可重复读”。真正的幻读必须满足两个条件：同一范围查询 + 当前读 + 结果集行数变化。RC下SELECT ... FOR UPDATE仍会读到新插入的行，并加锁——间隙未被锁定，插入不受阻，幻读就发生了。
- 快照读（纯
SELECT）在RC下可变，但不会引发幻读定义中的“行数突增”问题（因为插入行对快照不可见） - 当前读（带锁查询/写操作）在RC下永远读最新，且只加行锁，不加
Gap Lock，所以无法阻止其他事务向间隙中插入 - 你看到“两次
SELECT ... FOR UPDATE结果行数不同”，那一定是幻读；但两次纯SELECT结果不同，只是RC本色，不算幻读
RR下幻读也没被“自动解决”，只是默认启用Next-Key Lock
很多人误以为RR隔离级别“天然防幻读”，其实不然。RR只是让第一次快照读就固定ReadView，保证快照读结果一致；但它对当前读依然不做任何版本过滤——SELECT ... FOR UPDATE照样读最新数据。真正起作用的是InnoDB在RR下**默认启用Next-Key Lock（行锁 + 间隙锁）**，它把索引范围“封死”，让插入失败或阻塞。
- 如果没有索引，或查询条件无法走索引（如
WHERE name LIKE '%abc%'），Next-Key Lock退化为行锁，间隙敞口，幻读照常发生 - 如果更新语句命中唯一索引且等值查询（如
UPDATE t SET x=1 WHERE id = 5），InnoDB只加行锁，不加间隙锁，此时其他事务仍可在(5,10)间隙插入，导致后续范围查询出现幻读 - 显式使用
SELECT ... LOCK IN SHARE MODE或FOR UPDATE时，锁行为完全取决于查询是否走索引、是否范围扫描、是否唯一匹配——不能假设“用了RR就万事大吉”
为什么RC不加间隙锁？这是设计取舍
RC隔离级别的核心目标是“读已提交 + 高并发吞吐”，它放弃对“范围一致性”的保证。InnoDB在RC下禁用间隙锁（innodb_locks_unsafe_for_binlog=ON已被废弃，但逻辑保留），意味着所有当前读只锁定实际命中的记录，不封锁空隙。
- 好处：写冲突少、死锁概率低、主从复制延迟更可控（尤其ROW格式下）
- 代价：业务层必须自行处理幻读风险，比如用
SELECT ... FOR UPDATE配合唯一约束校验，或改用应用层分布式锁 - 典型踩坑：订单系统用
SELECT COUNT(*) WHERE status = 'pending'判断能否下单，再INSERT；RC下两次查询之间可能有新pending单插入，导致超发——这不是bug，是RC的明确行为
幻读不是MVCC的失效，而是你混淆了快照读与当前读的边界；也不是RR的承诺，而是你依赖了InnoDB在RR下默认开启的Next-Key Lock机制。一旦查询不走索引、或用了READ COMMITTED，那些“理所当然”的一致性就立刻消失——别怪隔离级别，要查执行计划和锁监控（INFORMATION_SCHEMA.INNODB_TRX + INNODB_LOCKS）。
