MySQL的RR隔离级别无法完全避免幻读，根本原因是快照读与当前读语义冲突：快照读基于事务启动时的ReadView且不加锁，而当前读访问最新数据并加Next-Key Lock，但其生效受索引、条件类型等多重限制。
MySQL 的 RR 隔离级别不能完全避免幻读，根本原因不是“锁没加好”，而是快照读和当前读共存于同一事务时，语义天然冲突——前者固化视图，后者穿透视图加锁，中间插入的新行对前者不可见、对后者可见。
快照读不加锁，也不阻止插入
RR 下的普通 SELECT 是快照读：事务启动时生成一个 ReadView，后续所有无锁 SELECT 都复用它。哪怕其他事务插入并提交了新行，只要其 DB_TRX_ID 大于当前事务的 up_limit_id，就不会出现在结果里。
- 这看起来“没幻读”，其实是 MVCC 的副作用，不是隔离级别本身保证了范围稳定性
-
SELECT * FROM t WHERE status = 'active'执行两次结果一致，不代表防住了幻读；只是你没做写操作，没暴露语义断层 - 快照读不加任何锁（包括间隙锁），既不阻塞插入，也不感知新提交的行
当前读才触发 Next-Key Lock，但只在特定条件下生效
SELECT ... FOR UPDATE、UPDATE、DELETE 属于当前读，InnoDB 必须访问最新已提交数据，并尝试加 Next-Key Lock（记录锁 + 间隙锁）。但它有三重硬约束：
-
WHERE字段必须有有效索引：若name = 'Alice'的name列无索引，InnoDB 退化为全表扫描，间隙锁失效 - 必须是范围条件：
WHERE id > 100会锁住(100, +∞)；而WHERE id = 100（主键等值）只加记录锁，不锁间隙，别人仍可在 99 和 101 之间插入 - 非唯一二级索引上等值查询（如
INDEX(b)，b=10有多行），InnoDB 向右扫描直到第一个不满足条件的索引项，锁住整个扫描区间，容易漏锁或过度锁
混用快照读与当前读必然导致幻读暴露
这是生产中最常踩的坑：事务内先用快照读判断状态，再用当前读修改，最后又用快照读验证——三次读取的数据视图不一致。
- 事务 A：
SELECT COUNT(*) FROM orders WHERE user_id = 123得 0 → 事务 B 插入user_id = 123并提交 → 事务 A 执行INSERT INTO orders ...（无唯一冲突）→ 最后SELECT发现多出 1 行 - 问题不在 RR 失效，而在第一次
SELECT基于旧ReadView，第二次INSERT或UPDATE是当前读，直接看到并锁定最新数据 - 如果你依赖快照读结果做存在性校验、计数决策或业务分支判断，就等于把逻辑建立在“可能过期”的视图上
间隙锁不是万能的，它只保护加锁之后的插入
Next-Key Lock 只能阻止“加锁之后”的插入，无法追溯保护“加锁之前”已存在的快照盲区。
- 事务 A 先执行
SELECT * FROM t WHERE id > 10（快照读，无锁）→ 事务 B 插入id = 15并提交 → 事务 A 再执行UPDATE t SET c = 1 WHERE id > 10（当前读，加锁）→ 此时幽灵行已存在，被一并更新 - 间隙锁的覆盖范围动态依赖 B+ 树遍历路径：索引结构、是否存在对应记录、是否唯一，都会影响最终锁住哪些
(gap_start, record]区间 - 没有索引、LIKE '%abc'、函数索引未命中、隐式类型转换导致索引失效——这些都会让间隙锁退化，幻读风险陡增
真正可控的方式不是寄希望于 RR 默认行为，而是主动控制读取模式：需要强一致性，就统一用 SELECT ... FOR UPDATE 开头；要避免语义错位，就别在同一事务里交替使用快照读和当前读。最易被忽略的一点是：即使加了锁，如果索引设计不合理或查询条件写法不当，锁根本不会按你预期的方式生效。
