Next-Key Lock 是 Record Lock 与 Gap Lock 的组合，仅在 REPEATABLE READ 级别下由 InnoDB 自动启用，用于防止幻读，锁定左开右闭区间（如 (90, 102]），其加锁范围取决于索引类型、查询条件及数据分布。
Next-Key Lock 是什么？一句话说清
Next-Key Lock 不是新锁类型，而是 Record Lock（锁某一行） + Gap Lock（锁两个值之间的空隙）的组合体，只在 REPEATABLE READ 隔离级别下由 InnoDB 自动启用，专为堵住幻读而生。
它锁的是「左开右闭区间」，比如 (90, 102]：不锁 90 这个点，但锁 102 这行 + 所有 90～102 之间的插入可能。你没写 FOR UPDATE 或 LOCK IN SHARE MODE，它就不会触发；一旦用了，影响远超直觉。
什么时候真正用上 Next-Key Lock？看查询方式
加锁不是拍脑袋全表扫，而是严格按索引查找路径走，只锁「访问到的索引项」及其对应区间。关键看三点：隔离级别、是否带锁读、查询条件类型。
-
SELECT ... WHERE id = 15 FOR UPDATE（主键等值查）→ 退化为纯Record Lock，只锁 id=15 这一行 -
SELECT ... WHERE age = 25 FOR UPDATE（普通索引等值查，且 age=25 存在）→ 锁(24, 25]和(25, 26]这类相邻间隙，实际可能卡住 age=25.5 的插入（如果字段允许小数） -
SELECT ... WHERE age > 30 FOR UPDATE（范围查）→ 典型 Next-Key 场景，比如当前最大 age 是 35，就可能锁(30, 35]和(35, +∞) -
WHERE字段没索引 → InnoDB 退化为全表扫描，对每条聚簇索引记录都加 Next-Key Lock，相当于整张表被锁死，极易阻塞其他事务
为什么必须靠它防幻读？MVCC 为啥不行
MVCC 能挡脏读、不可重复读，但对 INSERT 无感——它不改旧行，只加新行，快照里自然看不到“未来插入”的数据。幻读的本质是：同一事务内，两次相同范围查询，第二次多出新插入的行。
仅靠 Record Lock：能锁住已存在的 id=102，但拦不住别人插 id=101；
仅靠 Gap Lock：能锁 (90, 102) 防插入，但若已有 id=101，它又不锁这行本身，别人还能改它；Next-Key Lock 合力出手：既锁命中行，又锁它左边间隙，真正封死“该范围内增删改”的所有可能。
实战中最容易踩的坑
你以为只锁了 WHERE 条件里的值，其实锁了一整片区域；你以为查不到的记录就没事，结果它锁了整个空隙；你以为只是 SELECT，结果加了锁还阻塞 INSERT —— 这些都是 Next-Key Lock 的隐形杀伤力。
- 看似
WHERE age = 25，但如果 age 是普通索引，且表里有 age=24 和 age=26，那它实际锁的是(24, 26]，别人插 age=25.5 也会被卡住 -
UPDATE ... WHERE只锁命中的行（Record Lock），除非 WHERE 是范围条件；但SELECT ... FOR UPDATE在 RR 级别下一定走 Next-Key，行为不一致 - 事务中执行
SELECT ... FOR UPDATE后忘了COMMIT或ROLLBACK，锁会一直挂着，后续 INSERT/UPDATE 可能无限等待，直到锁超时（默认 50 秒）
最复杂也最容易被忽略的一点：Next-Key Lock 的加锁范围高度依赖索引结构和现有数据分布，不是光看 SQL 就能推断出来的；想准确定位，得结合 EXPLAIN、INFORMATION_SCHEMA.INNODB_LOCKS（或 8.0+ 的 performance_schema.data_locks）和实际数据值交叉验证。
