mysql如何防止数据库幻读现象_InnoDB间隙锁NextKeyLock机制-mysql教程-PHP中文网

MySQL RR隔离级别需配合当前读、索引条件及范围查询才能触发Next-Key Lock防幻读；无索引或等值查询仅加记录锁，无法锁间隙，故status='pending'防不住而id>10可防住。

mysql如何防止数据库幻读现象_innodb间隙锁nextkeylock机制

MySQL 的 RR 隔离级别本身不“自动防止幻读”，必须配合当前读 + 索引条件 + 范围查询，才能触发 Next-Key Lock 生效；否则幻读照常发生。

为什么 `SELECT * FROM t WHERE id > 10` 可能防住幻读，而 `SELECT * FROM t WHERE status = 'pending'` 防不住

Next-Key Lock 是 Record Lock（锁记录）和 Gap Lock（锁间隙）的组合，但它只在满足两个硬性前提时才启用：查询走索引、且是范围条件。前者没索引，InnoDB 只能全表扫描，退化为表级锁或干脆不锁间隙；后者是等值查询且命中唯一索引（如主键），InnoDB 只加 Record Lock，不锁前后间隙——别人照样能在 id=9 和 id=11 之间 INSERT 新行。

id > 10：若 id 是主键或二级索引，会锁住 (10, +∞) 这个区间，新插入 id=15 的行会被阻塞
status = 'pending'：若 status 字段无索引，InnoDB 不知道“pending”在哪儿，无法界定间隙，只能锁表或不锁
即使 status 有索引，但用的是 LOCK IN SHARE MODE（S 锁），InnoDB 默认不加 Gap Lock，只锁命中的行

怎么确认你的查询真的用了 Next-Key Lock

不能光看隔离级别设成了 REPEATABLE READ，得查锁的实际行为。最直接的方式是查 performance_schema.data_locks 表，过滤出当前事务的锁记录：

SELECT LOCK_TRX_ID, LOCK_MODE, LOCK_DATA 
FROM performance_schema.data_locks 
WHERE LOCK_TRX_ID = '你的事务ID';

关键看 LOCK_MODE 字段：出现 RECORD & GAP 或 RECORD & NEXT-KEY 才算生效；如果只有 RECORD，说明只是行锁；如果压根没记录，可能连锁都没加。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

另一个验证方式：在事务 A 中执行 SELECT * FROM t WHERE id > 5 FOR UPDATE，然后在事务 B 中尝试 INSERT INTO t VALUES (6, ...) —— 若被阻塞，说明间隙被锁住
注意：SHOW ENGINE INNODB STATUS\G 中的 lock_mode X locks rec but not gap 明确表示没用上间隙部分

哪些配置或写法会让 Next-Key Lock “悄悄失效”

Next-Key Lock 很依赖运行时上下文，稍有偏差就降级。常见失效点包括：

MySQL 8.0+ 中残留了 innodb_locks_unsafe_for_binlog = ON（已废弃但旧配置可能还在），它会强制禁用 Gap Lock
使用了 SELECT ... LOCK IN SHARE MODE + 唯一索引等值查询 → 只加 S 类 Record Lock，不锁间隙
查询条件含函数或类型隐式转换，比如 WHERE DATE(create_time) = '2026-04-17'，导致索引失效，进而无法启用 Next-Key
事务中先执行了快照读（普通 SELECT），再执行当前读，MVCC 视图已固定，但锁是后加的，间隙保护只对后续插入生效，对之前已发生的插入无回溯能力