为什么MySQL中即使使用了主键更新也会出现Gap Lock？-mysql教程-PHP中文网

gap lock是innodb在rr隔离级别下锁定索引间隙以防止幻读的机制，仅对当前读生效，不锁记录本身但阻止插入，常见于非主键索引查询、范围查询及查无结果场景。

为什么mysql中即使使用了主键更新也会出现gap lock？

主键更新本身不会加 Gap Lock，但 WHERE 条件没走主键索引时，就会触发 Gap Lock —— 这是绝大多数人踩坑的根源。

UPDATE 语句的 WHERE 条件没命中主键索引

很多人以为写了 UPDATE t SET ... WHERE id = ? 就一定走主键，其实不然。常见失配场景包括：

id 字段是字符串类型，但传入的是数字（如 WHERE id = 123），触发隐式类型转换，导致索引失效
字段上有函数包装，比如 WHERE CAST(id AS CHAR) = '100' 或 WHERE CONCAT(id, '') = '100'
使用了 OR 条件且其中一侧无法走索引，例如 WHERE id = 100 OR name LIKE '%x%'，优化器可能放弃主键索引
表统计信息过期或执行计划被固化（sql_plan_baseline），实际走了全表扫描

一旦不走主键索引，InnoDB 在 RR 隔离级别下会对**所有扫描过的记录加 X 锁、所有扫描经过的间隙加 Gap Lock** —— 此时哪怕你只改一行，锁住的可能是整段索引区间。

UPDATE 主键值本身（即修改主键字段）

这不是 Gap Lock，但比 Gap Lock 更重：它触发的是“删旧 + 插新”两阶段操作，每步都加 X 锁，且会连带重建所有二级索引。关键点在于：

MySQL

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

下载

UPDATE t SET id = 101 WHERE id = 1 实际执行逻辑等价于：DELETE FROM t WHERE id = 1 + INSERT INTO t (id, ...) VALUES (101, ...)
插入新主键时，若目标位置已被其他事务用 Gap Lock 锁定（比如另一个事务正在 WHERE id BETWEEN 100 AND 102 范围内操作），就会等待
二级索引项必须全部重写，每条都需回查聚簇索引 → 锁扩散远超 SQL 表面范围

事务中混用非主键条件与主键更新

这是最隐蔽的 Gap Lock 来源。例如：

BEGIN;
UPDATE t SET status = 'done' WHERE create_time > '2026-06-01'; -- 走 create_time 索引，加 Next-key Lock
UPDATE t SET id = id + 1 WHERE id = 100; -- 看似主键更新，但前一条语句已锁住包含 id=100 的间隙
COMMIT;

第二条语句虽然条件精确匹配主键，但 InnoDB 不保证“先释放前锁再加新锁”。如果前一个语句在 create_time 索引上锁住了 (95, 105] 区间，而 id = 100 正好落在其中，第二条 UPDATE 就会被阻塞 —— 不是因为它自己加了 Gap Lock，而是被前面语句的 Gap Lock 拦住了。

如何快速确认是否真有 Gap Lock？

别猜，直接看锁信息：

执行 SELECT * FROM performance_schema.data_locks;（MySQL 8.0+），关注 LOCK_MODE 字段含 GAP 或 NEXT-KEY 的行
用 SHOW ENGINE INNODB STATUS\G 查看 TRANSACTIONS 段，找 lock_mode X locks gap before rec 类提示
在测试环境开启死锁日志：SET GLOBAL innodb_print_all_deadlocks = ON;，死锁日志里会明确写出 Gap Lock 的锁定范围