MySQL RR级别未完全解决幻读，根本原因是快照读（依赖ReadView、不加锁）与当前读（访问最新版本、加next-key锁）行为不一致，混用二者导致语义断裂；且间隙锁仅在索引范围查询时生效，无索引或等值查询时失效。
快照读和当前读行为不一致是根本原因
MySQL InnoDB 的 REPEATABLE READ 隔离级别下，幻读之所以“可能出现”，核心在于它对两类读操作区别对待：SELECT（快照读）和 SELECT ... FOR UPDATE / UPDATE / DELETE（当前读）。前者依赖事务启动时生成的 Read View，后者直接访问最新已提交版本并加锁。
这意味着：同一事务中，第一次 SELECT * FROM t WHERE id > 100 看不到其他事务插入的新行（快照读），但紧接着执行 UPDATE t SET x=1 WHERE id > 100 却能命中并修改那条新行（当前读）——这不是数据“变多了”，而是读取机制切换导致的语义断裂。
- 快照读不加锁、不阻塞插入，只按事务启动时刻的快照过滤可见行
- 当前读必须加锁（
next-key lock），但锁范围取决于查询是否走索引；无索引时仅锁记录，不锁间隙 - 事务内混合使用快照读和当前读，天然构成幻读观察窗口
间隙锁失效场景会暴露幻读
很多人误以为只要用了 REPEATABLE READ 就自动有间隙锁兜底。实际上，gap lock 和 next-key lock 只在**查询条件能利用索引定位范围**时才生效。一旦 WHERE 字段没索引，InnoDB 退化为全表扫描，此时只对实际读到的行加行锁，间隙完全开放。
典型例子：SELECT * FROM user WHERE name = 'Alice' FOR UPDATE，若 name 无索引，InnoDB 不会对 'Alice' 前后间隙加锁，其他事务仍可插入 name = 'Alice' 的新记录，后续同条件 SELECT ... FOR UPDATE 就会多出一行。
- 唯一索引等值查询：只加行锁（
record lock），不涉及间隙 - 普通索引范围查询（如
id > 100）：加next-key lock，覆盖行 + 间隙 - 无索引字段查询：即使
FOR UPDATE，也仅对扫描到的每行加record lock，间隙不锁
先查后更逻辑天然触发幻读
业务中最常见的幻读发生点，是“判断是否存在 → 再插入”的模式。比如用户注册时先 SELECT COUNT(*) FROM users WHERE email = 'a@b.com' 得到 0，再 INSERT INTO users...。这个 SELECT 是快照读，不阻止并发插入；而 INSERT 本身不加任何间隙锁，两个事务几乎同时执行就会导致重复插入。
注意：即使你在 SELECT 后立刻加 FOR UPDATE，如果 email 没索引，同样无法锁住“该邮箱未来可能插入的位置”。
-
INSERT语句从不加间隙锁，只在插入后对新行加行锁 - 唯一约束可以拦截重复插入，但不解决“两次查询结果不一致”这个幻读定义本身
- 应用层用
INSERT ... ON DUPLICATE KEY UPDATE或分布式锁，比依赖隔离级别更可靠
不是 MySQL 实现有缺陷，而是标准与工程的权衡
SQL 标准中 REPEATABLE READ 并不要求避免幻读，MySQL InnoDB 的实现已经比标准更进一步——它用 MVCC + next-key lock 在多数写冲突场景下压制了幻读。但这种压制是有前提的：查询需走索引、避免快照读/当前读混用、不依赖“查无结果就安全”的直觉。
真正容易被忽略的是：幻读不是“bug”，而是隔离级别能力边界的自然体现。当你发现幻读，第一反应不该是“为什么没防住”，而是检查那条出问题的 SELECT 是否走了索引、是否和后续写操作处于同一读视图语义下、以及业务逻辑是否隐含了对“绝对不存在”的强假设。
