幻读只在“当前读”下真实发生
MySQL 的可重复读（RR）隔离级别下，普通
SELECT是快照读，靠 MVCC 保证不看到其他事务插入的新行——所以**不会幻读**。真正出问题的是那些显式加锁的“当前读”语句：
SELECT ... FOR UPDATE、
SELECT ... LOCK IN SHARE MODE、
UPDATE、
DELETE。它们读取最新版本数据，并触发加锁逻辑，但若锁范围没覆盖“间隙”，新插入就逃逸了。 快照读（
SELECT）：事务启动时拍个快照，后续查不到别人插入的行 → 安全 当前读（
SELECT ... FOR UPDATE）：每次查都读最新版，且要加锁 → 若只锁住已有记录，不锁间隙，别人就能插进来 典型错误场景：事务 A 先
SELECT * FROM t WHERE age > 25 FOR UPDATE，事务 B 紧接着
INSERT INTO t VALUES (..., 30)→ A 第二次执行相同语句时会看到新行
为什么行锁挡不住插入？得靠 next-key lock
InnoDB 的行锁（record lock）只锁住索引记录本身，对两个记录之间的“空隙”（gap）无能为力。而
INSERT操作不修改任何现有记录，只往间隙里写——所以必须用
next-key lock（记录锁 + 间隙锁）来封住整个范围。 假设
age字段有索引，且当前存在
age=20和
age=35两行 → 那么
WHERE age > 25的 next-key lock 会锁住区间
(25, 35]，同时包含间隙
(25, 35)和记录
35但如果查询条件没走索引（例如
WHERE name LIKE '%abc%'），InnoDB 可能退化为锁全表或锁主键所有间隙，性能暴跌 唯一索引的等值查询（
WHERE id = 10）只加 record lock，不加 gap lock —— 这是例外，但跟幻读关系不大
常见误判：以为“可重复读=彻底防幻读”
很多开发者看到文档说“RR 解决幻读”，就认为万事大吉。实际上，这个“解决”是有前提的：必须用对语句、建对索引、理解锁行为。否则很容易掉坑里。
错误做法：在事务里先做一次普通SELECT（快照读），再做
UPDATE ... WHERE xxx（当前读）→ 中间可能被插入，UPDATE 会生效到新行，导致业务逻辑错乱 错误配置：表没索引，或查询条件无法命中索引 →
SELECT ... FOR UPDATE变成锁表级扫描，锁粒度失控 典型报错现象：事务 B 执行
INSERT卡住不动，日志显示
Lock wait timeout exceeded→ 说明 A 的 next-key lock 确实生效了；但反过来，如果 B 插入成功了，大概率是 A 的锁没覆盖到那个间隙
实操建议：三步定位与收敛幻读风险
别靠猜，用工具看锁、用语句控锁、用设计减依赖。
查锁状态：SELECT * FROM performance_schema.data_locks;或
SHOW ENGINE INNODB STATUS\G，重点看
LOCK_MODE是
RECORD还是
NEXT-KEY，以及
LOCK_DATA覆盖范围 强制当前读并锁全范围：事务开头就执行
SELECT ... FOR UPDATE，而不是等要用时才查；WHERE 条件尽量走索引，避免全表扫描 业务层兜底：对强一致性要求高的场景（如库存扣减、资金流水），考虑用
SELECT ... FOR UPDATE+ 重试，或升级到
SERIALIZABLE（但并发会明显下降）
幻读不是 bug，是 RR 隔离级别在“性能”和“一致性”之间做的权衡结果。它暴露的往往不是 MySQL 的缺陷，而是查询是否真的锁住了你“以为锁住”的那个范围——而这，永远取决于索引、语句、事务顺序三者的实时组合。
