17370845950

幻读主要发生在可重复读级别下，指同一范围查询结果集行数不一致；InnoDB通过MVCC+间隙锁解决当前读幻读，快照读的“幻影”属正常行为；应用层可用唯一索引+重试机制高效规避。

MySQL 中的幻读问题，主要出现在可重复读（Repeatable Read）隔离级别下，当一个事务中前后两次执行相同的范围查询，结果集的行数不一致（比如中间被其他事务插入了新记录），就发生了幻读。

理解幻读的本质

幻读不是读到了“不存在”的数据，而是读到了“新插入”的数据。它和不可重复读的区别在于：不可重复读是同一行数据被修改，幻读是新行被插入或删除导致结果集变化。

在 MySQL 的 InnoDB 引擎中，RR 级别通过多版本并发控制（MVCC）+ 间隙锁（Gap Lock）来解决大部分幻读问题，但仅限于当前读（如 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE）。普通的快照读（普通 SELECT）仍可能看到“幻影”，但这属于 MVCC 正常行为，不视为事务异常。

用间隙锁阻止插入（当前读场景）

当需要严格避免幻读（例如做范围校验后再插入），应使用当前读并依赖间隙锁锁定范围：

• 执行 SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE;，InnoDB 不仅锁住已有记录，还会锁住 (10,20) 这个间隙，阻止其他事务在此区间插入新行
• 若查询条件无索引或索引失效，间隙锁会升级为表锁，严重影响并发，务必确保条件走索引
• 主键或唯一索引上的等值查询（如 WHERE id = 15）只加记录锁，不加间隙锁；而范围查询（>、、BETWEEN）才会触发间隙锁

升级到串行化（Serializable）隔离级别

这是最彻底的方案，MySQL 会自动将所有普通 SELECT 隐式转为 SELECT ... LOCK IN SHARE MODE，使读操作也加锁，完全避免幻读。

但代价是并发性能大幅下降，写阻塞读、读也阻塞写，仅适用于对一致性要求极高、并发压力极低的场景（如金融核心批处理）。

应用层配合：使用唯一约束 + 重试机制

对于“检查后插入”类典型幻读场景（如防止重复下单），推荐更轻量的解法：

• 在业务字段上建立唯一索引（如订单号、用户+商品组合）
• 先尝试插入，捕获唯一键冲突错误（ER_DUP_ENTRY）
• 根据业务逻辑决定是返回失败还是重查后提示“已存在”

这种方式不依赖锁，性能好，且天然规避幻读引发的逻辑错乱，比纯靠数据库锁更健壮。

幻读不是 bug，是隔离级别与实现机制权衡的结果。InnoDB 在 RR 下已通过间隙锁覆盖了绝大多数写入型幻读，关键是要分清快照读和当前读，合理选择锁策略与应用设计。