Next-Key Lock锁定范围是动态计算的左开右闭区间，取决于索引结构和实时数据分布；例如非唯一索引status值为0,0,1,3时，WHERE status=0 FOR UPDATE会锁(-∞,0]和(0,1]，而非仅status=0的记录。
Next-Key Lock 的锁定范围不是写死的，而是动态算出来的
很多人以为 WHERE status = 0 只会锁住 status = 0 的那些行，但实际加锁范围取决于索引结构和当前数据分布。InnoDB 拿到查询条件后，先定位索引位置，再按「左开右闭区间」向上/向下延伸——这个延伸过程不看业务语义，只看索引树里相邻键值。
比如 status 是普通索引，现有值为 0, 0, 1, 3，那么 WHERE status = 0 FOR UPDATE 实际锁定的是 (-∞, 0] 和 (0, 1] 两个区间，而不是“所有 status=0 的记录”本身。插入 status = 0 或 status = 1 都可能被阻塞。
常见错误现象：
- 明明只查一行，却卡住后续大量
INSERT -
SELECT ... FOR UPDATE执行完，INSERT等待超时，但SHOW ENGINE INNODB STATUS里看不到明显锁冲突
非唯一索引 + 等值查询 = 默认启用 Next-Key Lock
这是最常被低估的触发点。主键或唯一索引的等值查询（如 WHERE id = 123）会退化为纯记录锁；但只要索引是非唯一的（哪怕只有一条匹配），InnoDB 就认为“可能还有别的同值行”，于是锁定该值所在间隙 + 记录本身。
示例场景：
- 表有
KEY idx_status(status)，且status值大量重复 - 执行
SELECT * FROM orders WHERE status = 0 ORDER BY create_time LIMIT 1 FOR UPDATE - 即使只命中 1 行，也会锁住
status = 0对应的所有可能插入位置，包括status = 0和下一个不同status值之间的整个间隙
后果是：其他事务插入 status = 0 新单会被阻塞，哪怕那条新单的 create_time 完全不重叠。
LIMIT 1 并不能缩小 Next-Key Lock 范围
LIMIT 是在加锁之后才生效的过滤动作。InnoDB 先完成索引扫描、加锁，最后才取前 N 行返回。也就是说，LIMIT 1 不影响加锁逻辑，只影响结果集大小。
典型踩坑：
- 定时任务用
SELECT ... WHERE status = 0 ORDER BY create_time LIMIT 1 FOR UPDATE拿单 - 由于
status是非唯一索引，InnoDB 扫描所有status = 0的索引项，并对每个匹配项及其后间隙加 Next-Key 锁 - 哪怕最终只返回 1 行，锁已经覆盖了整个
status = 0的索引段，甚至延伸到status = 1的开头
性能/兼容性影响：MySQL 8.0+ 支持 SKIP LOCKED，可绕过已锁行继续找可用行，但前提是显式加上，且不能解决间隙锁本身。
没走索引时，Next-Key Lock 会退化成事实上的表级锁
当查询条件无法使用索引（例如 WHERE JSON_CONTAINS(meta, '"paid"') 或 WHERE LEFT(name, 3) = 'abc'），InnoDB 会做聚簇索引全扫描，对每一条记录加记录锁，同时对所有间隙加间隙锁——相当于把整张表的索引树从头到尾锁一遍。
这种情况下：
-
INSERT、UPDATE、DELETE几乎全部阻塞 -
SHOW PROCESSLIST看不到明显慢查询，但连接数持续上涨 -
performance_schema.data_locks中会出现大量LOCK_MODE: X, LOCK_TYPE: RECORD和GAP混合条目
最容易被忽略的一点：某些看似能走索引的表达式（如函数包裹列、隐式类型转换）会导致索引失效，进而触发全表范围的 Next-Key 锁。检查执行计划比看 SQL 表面更可靠。
