幻读是 MySQL 事务中一种典型的并发异常现象，指同一个事务内，两次执行相同范围的 SELECT 查询，结果集的行数不一致——第二次查到了第一次没看到的新行。这些“凭空出现”的记录，就像幻觉一样，因此叫“幻读”。
幻读发生的典型场景
常见于以下操作流程：
事务 A 执行SELECT * FROM users WHERE age > 25，返回 10 条记录； 事务 B 插入一条满足条件的新记录（如
INSERT INTO users (name, age) VALUES ('Alice', 28)）并提交；
事务 A 再次执行同样查询，返回 11 条记录——多出的那一行就是“幻行”。
注意：这不是数据被修改（那是不可重复读），也不是读到未提交数据（那是脏读），而是别的事务插入了新数据，且已提交。
为什么 RR 隔离级别下还会出现幻读？
MySQL 默认的可重复读（RR）通过 MVCC 实现快照读，能避免脏读和不可重复读，但只对已存在的记录生成一致性视图。对于尚未存在的间隙（gap），MVCC 不覆盖——所以其他事务仍可在这些间隙中插入新行。
关键点：
快照读（普通 SELECT）在 RR 下不会看到新插入行，表面不幻读； 但一旦混用当前读（如SELECT ... FOR UPDATE、
UPDATE、
DELETE），就会触发 gap 锁或 next-key 锁，而锁的范围是否覆盖插入点，决定了是否真能拦住幻行； 如果事务先快照读、后当前读，前后视图不一致，就暴露幻读。
真正有效的解决方式
不是靠“换隔离级别”一刀切，而是结合场景选择合适手段：
用 next-key lock 主动加锁：在关键查询后立刻加锁，例如SELECT * FROM users WHERE age > 25 FOR UPDATE，InnoDB 会锁定匹配范围 + 相邻间隙，阻止其他事务插入； 改用串行化（SERIALIZABLE）：MySQL 会自动为所有 SELECT 隐式加上共享锁，彻底阻塞插入，但并发性能急剧下降，仅适合低吞吐强一致性场景； 应用层配合唯一约束或重试逻辑：比如“先查后插”逻辑，直接用
INSERT IGNORE或
ON DUPLICATE KEY UPDATE，靠主键/唯一索引拦截重复插入，避免因幻读导致的主键冲突报错。
容易忽略的关键细节
幻读是否发生，高度依赖实际执行的是快照读还是当前读，以及索引类型：
没有索引的 WHERE 条件 → 可能升级为表锁，影响大但不一定防幻读； 主键或唯一索引等值查询 → 加的是 record lock，不锁间隙，无法防幻读； 普通索引、范围查询（如>、
BETWEEN）→ InnoDB 默认使用 next-key lock（record lock + gap lock），这才是防幻读的核心机制。
