next-key lock锁的是左开右闭区间，由record lock（锁记录本身）和gap lock（锁记录间间隙）组合而成，用于rr隔离级别下防止幻读。
MySQL在REPEATABLE READ隔离级别下，靠Next-Key Lock堵住“能插却没被锁住”的空子，才真正拦住幻读——不是靠猜、不是靠运气，是靠锁住记录+间隙的组合拳。
Next-Key Lock到底锁什么
它不是一种新锁类型，而是Record Lock（行锁）和Gap Lock（间隙锁）的自动合体。InnoDB在执行范围查询的CURRENT READ（比如SELECT ... FOR UPDATE或UPDATE带条件）时，会默认启用它。
关键在于“锁区间”：比如索引上有值10、20、30，查询WHERE id BETWEEN 15 AND 25，Next-Key Lock实际锁定的是(10, 20]和(20, 30]这两个左开右闭区间——既锁住id=20这行，也锁住10 和<code>20 这两段空白地带。
- 只查单值（如
WHERE id = 20）且该值存在 → 只加Record Lock，不锁间隙 - 查单值但该值不存在（如
WHERE id = 25，而表里没有25）→ 加Gap Lock，锁住(20, 30)这个间隙 - 范围查询（
BETWEEN、>、等）→ 默认加<code>Next-Key Lock，覆盖所有命中行+相邻间隙
为什么只靠MVCC不够防幻读
MVCC负责SNAPSHOT READ（普通SELECT），它让事务看到“自己开始那一刻”的快照，对已存在记录的读取确实不会看到新插入行——但这只对“不加锁的读”有效。
一旦你写代码里混用了SELECT（快照读）和UPDATE ... WHERE（当前读），问题就来了：
- 第一次
SELECT COUNT(*) FROM orders WHERE status = 'pending'→ 走MVCC，看到10条 - 别人此时
INSERT INTO orders ... VALUES ('pending')并提交 - 你接着
UPDATE orders SET status = 'processing' WHERE status = 'pending'→ 这是CURRENT READ，触发Next-Key Lock，但锁的范围取决于status字段是否有索引、索引类型、以及当前索引树结构 - 如果
status没索引，InnoDB可能全表扫描+行锁，间隙锁失效 → 新插入的行没被锁住，UPDATE会改掉它，第二次SELECT就多出1条
所以幻读漏洞往往不是MVCC坏了，而是你没意识到UPDATE那一句已经切换到CURRENT READ模式，而它的锁行为完全依赖索引和查询条件。
实战中容易踩的三个坑
Next-Key Lock生效有硬性前提，漏掉任何一个，幻读就可能复活：
-
innodb_locks_unsafe_for_binlog设为ON（旧版本MySQL）或隔离级别被降为READ COMMITTED→Gap Lock被禁用，只剩Record Lock，间隙可自由插入 -
WHERE条件没走索引（例如对非索引列查询，或索引失效：隐式类型转换、函数包裹字段）→ InnoDB退化为表级扫描，间隙锁无法精确定位，基本失效 - 查询条件是
!=或NOT IN→ InnoDB不使用Next-Key Lock，只加Record Lock，间隙敞开着
验证是否生效最直接的办法：在事务A中执行SELECT ... FOR UPDATE后，立刻在事务B中尝试INSERT符合该查询范围的新行，看是否被阻塞。别信文档，要亲眼看到INSERT hang住，才算锁到位。
真正难的不是理解Next-Key Lock怎么工作，而是判断你的那条UPDATE或SELECT ... FOR UPDATE语句，在真实数据分布和索引结构下，到底锁住了哪些间隙——这得看EXPLAIN输出的key和Extra字段，再结合SHOW ENGINE INNODB STATUS\G里的locks段落。纸上谈兵容易，落到具体SQL上，一行索引缺失就能让幻读重现。
