mysql幻读是怎么出现的_mysql并发问题说明-mysql教程-PHP中文网

幻读只在“当前读”下真实发生；快照读靠MVCC避免幻读，而SELECT...FOR UPDATE等当前读若未用next-key lock覆盖间隙，则可能读到新插入行。

mysql幻读是怎么出现的_mysql并发问题说明

幻读只在“当前读”下真实发生

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 解决幻读”，就认为万事大吉。实际上，这个“解决”是有前提的：必须用对语句、建对索引、理解锁行为。否则很容易掉坑里。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

错误做法：在事务里先做一次普通 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（但并发会明显下降）