MySQL RR隔离级别无法完全避免幻读，根本原因在于快照读依赖MVCC提供一致性视图但不锁间隙，而当前读依赖Next-Key Lock防止插入，两者机制分离且混合使用时导致同一事务内读取结果不一致。
MySQL RR 隔离级别无法完全避免所有幻读，根本原因不是它“没做”，而是它对快照读和当前读采用了两套互不兼容的机制：一套靠 MVCC 固定视图（不加锁），一套靠 Next-Key Lock 封锁间隙（只在当前读触发）。两者混用时，结果集自然不一致。
快照读不锁间隙，但业务逻辑却依赖它做判断
RR 下普通 SELECT 是快照读，事务启动时生成一个 ReadView，之后所有该类查询都复用它。新插入的行只要 DB_TRX_ID 大于 up_limit_id，就不可见——所以你两次 SELECT * FROM t WHERE b = 1 看到的行数一样。
但这只是“看起来没幻读”。问题出在后续动作：
- 你用快照读拿到 1 行，认为“只有这一条满足条件”，接着执行
UPDATE t SET c = 100 WHERE b = 1（当前读）——它会看到事务 B 刚插入的那条b = 1的新行，并加锁； - 更新完再用快照读查一遍，又只剩 1 行；
- 但如果这时你补一句
SELECT * FROM t WHERE b = 1 FOR UPDATE，突然就变成 2 行。
这不是数据错乱，是语义冲突：快照读回答“当时有哪些”，当前读回答“现在能锁住哪些”。业务代码若把两者当同一事实用，幻读感立刻出现。
Next-Key Lock 只在当前读生效，且严重依赖索引和查询类型
SELECT ... FOR UPDATE 或 UPDATE ... WHERE 能否防住幻读，取决于它是否真正触发了 Next-Key Lock。而这个锁只在满足以下条件时才完整生效：
- WHERE 条件必须走**索引**（主键、唯一索引、普通二级索引均可，但不能全表扫描）；
- 查询必须是**范围条件**（如
WHERE b > 1、WHERE b BETWEEN 1 AND 5），等值查询（WHERE b = 1）在非唯一索引上才锁间隙，唯一索引上只加记录锁； - 没有索引或
LIKE '%abc'这类无法走索引的条件，InnoDB 退化为行锁甚至表锁，间隙敞口； - 如果事务 B 在事务 A 执行当前读**之前**就插入并提交了新行，Next-Key Lock 根本来不及拦——它只阻塞后续插入，不回滚已存在数据。
例如：UPDATE t SET c = 1 WHERE b = 1，若 b 是唯一索引，InnoDB 只锁 b = 1 对应的那条记录，不锁 (1, next_b) 间隙，别人仍可插入另一个 b = 1（违反唯一约束会报错，但若 b 不是唯一索引，就真插进去了）。
显式加锁 ≠ 自动覆盖全部可能插入点
Next-Key Lock 锁的是索引树上的“区间”，不是业务语义上的“逻辑范围”。比如表里 b 值当前是 [1, 2, 4]，你执行 SELECT * FROM t WHERE b > 1 FOR UPDATE，实际锁住的是 (1, 2] 和 (2, 4] 两个间隙，以及 b = 2、b = 4 这两行。但若有人插入 b = 1.5，会被拦；插入 b = 3，也会被拦；可如果插入 b = 100，它落在 (4, +∞) 间隙外——而这个间隙是否被锁，取决于查询是否命中右边界（WHERE b > 1 会锁 (4, +∞)，但 WHERE b = 2 不会）。
更隐蔽的是：如果业务用 JSON_CONTAINS、函数索引、虚拟列等高级特性，且查询未命中对应索引路径，Next-Key Lock 彻底失效。
真正容易被忽略的点是：幻读不是“数据库坏了”，而是开发者把“一致性读”当成“强一致性操作”的前提。RR 提供的是两种隔离能力的拼图，但拼哪一块、怎么拼，得由你写 SQL 的方式决定——不是设个 transaction_isolation = 'REPEATABLE-READ' 就自动生效。
