幻读仅在当前读中发生，快照读因基于事务启动时的read view而天然免疫；rr级别下防幻读依赖next-key lock，但需同时满足索引命中、范围查询、当前读三个条件，缺一则失效。
幻读只在当前读中暴露，快照读天然免疫
MySQL 的可重复读（RR）隔离级别下，普通 SELECT 是快照读，事务启动时生成一个 Read View，后续所有快照读都基于该视图从 undo log 中回溯数据——这意味着其他事务插入的新行根本不会出现在结果里。所以如果你只做两次裸 SELECT，绝不会看到“多出一行”，也就不会触发幻读现象。
真正出问题的是当前读：SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE。这些操作绕过 MVCC 快照，直接读取最新已提交版本，并加锁。此时若无有效锁保护插入点，新行就会“冒出来”。
- 常见错误：误以为设成 RR 就万事大吉，结果在业务逻辑里混用快照读和当前读（比如先
SELECT判断存在性，再INSERT或UPDATE），导致语义断裂 - 典型症状：第一次
SELECT ... FOR UPDATE WHERE status = 1返回 3 行；中间别人插入status = 1的新记录并提交；第二次同样语句返回 4 行
间隙锁失效的三个关键条件
RR 下防幻读靠的是 next-key lock（行锁 + 间隙锁），但它不是自动生效的，必须同时满足：
-
WHERE条件必须命中 B+ 树索引（主键、唯一索引、普通二级索引均可），不能是函数索引、前缀索引未覆盖完整条件，也不能是LIKE '%abc'这类无法走索引的写法 - 查询必须是范围条件（如
id > 100、name BETWEEN 'a' AND 'z'）；等值查询（如id = 105）只锁单条记录及其左侧间隙，不锁右侧，新记录可能插在右边“漏掉” - 必须是当前读语句，快照读不触发任何间隙锁
只要缺一，InnoDB 就退化为仅加行锁，甚至全表扫描时不加任何间隙锁——这时插入完全自由，幻读必然发生。
唯一索引等值查询是个经典陷阱
很多人以为“有主键就安全”，但 InnoDB 对唯一索引的等值查询（如 WHERE id = 105）通常只加 record lock，不加间隙锁。这意味着：
- 事务 A 执行
SELECT * FROM t WHERE id = 105 FOR UPDATE→ 锁住 id=105 这一行 - 事务 B 插入
id = 106（假设表里当前最大 id 是 105）→ 不冲突，成功 - 事务 A 再执行一次相同查询 → 仍只看到 id=105，但若它下一步想“确保 id 在 [105, 110] 区间无数据”，逻辑就崩了
这不是 bug，是设计权衡：唯一性已由索引约束保证，InnoDB 认为没必要为单点查询封锁整个区间。但业务上若依赖“查无此值 → 安全插入”，就必须改用范围查询或显式加锁覆盖间隙。
INSERT 自身不加间隙锁，靠别人替你拦
这是最反直觉的一点：执行 INSERT INTO t VALUES (105, 'x') 时，InnoDB 并不主动申请间隙锁；它只是检查要插入的位置（比如主键 105）前后是否有被其他事务用 next-key lock 封锁的间隙。如果有，插入被阻塞；如果没有，直接写入。
所以幻读的本质不是“别人能插”，而是“你没锁住别人能插的地方”。解决方案不是堵 INSERT，而是让自己的查询提前把插入口焊死：
- 用
SELECT ... FOR UPDATE覆盖目标范围（如WHERE id >= 100 AND id ） - 在业务层用唯一约束兜底（
INSERT ... ON DUPLICATE KEY UPDATE），靠索引强制排他 - 避免“先查后插”模式，改用带条件的原子更新（如
INSERT IGNORE或应用层分布式锁）
真正难处理的从来不是技术方案，而是那些没建索引的字段、写了 OR 导致索引失效的 WHERE、以及开发时随手写的 SELECT * —— 它们让 next-key lock 彻底沉默，而你还在日志里找不出原因。
