MySQL中DELETE语句删除不存在的记录为什么也会加锁？-mysql教程-PHP中文网

delete未命中时加gap锁而非无锁，根本原因是rr级别下innodb对索引间隙的保守锁定；其与insert意向锁互斥，易引发阻塞和循环等待死锁。

mysql中delete语句删除不存在的记录为什么也会加锁？

DELETE WHERE 未命中时加的是 Gap 锁，不是“没锁”

很多人看到 DELETE FROM t WHERE id = 15 没删到任何行，就以为“什么锁都没加”，实际恰恰相反：在 REPEATABLE READ 隔离级别下，只要 WHERE 条件走了索引（主键或二级索引），InnoDB 就会锁定该值“本该存在”的间隙。比如表中现有 id = 10 和 id = 20 两行，执行该语句就会加 Gap lock 锁住开区间 (10, 20) —— 即便 id = 15 根本不存在。

为什么 Gap 锁会导致 INSERT 阻塞甚至死锁？

Gap lock 和 INSERT 所需的 insert intention lock 是互斥的。当事务 A 执行未命中的 DELETE 锁住 (10, 20) 后，事务 B 若执行 INSERT INTO t VALUES (15)，就必须申请插入意向锁，但立刻被阻塞。若此时事务 B 也执行了另一个未命中的 DELETE（比如 WHERE id = 18），再反向尝试插 15，A 和 B 就可能形成循环等待。

Gap 锁之间是兼容的，不会互相阻塞
但 Gap 锁与插入意向锁天然冲突，这是死锁高发点
Insert 意向锁是轻量、窄范围、按需申请；Delete 的 Gap 锁是“扫描即加”，范围宽、不可预测

怎么快速判断 DELETE 是否加了 Gap 锁？

最直接的方式是开启锁监控后查 INFORMATION_SCHEMA.INNODB_TRX 和 INNODB_LOCKS：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

SET GLOBAL innodb_status_output_locks = ON;
-- 然后执行你的 DELETE，再运行：
SHOW ENGINE INNODB STATUS\G

在输出的 LATEST DETECTED DEADLOCK 或 TRANSACTIONS 部分，留意是否有 lock_mode X locks gap before rec 这类描述。另外，用 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 查看长时间 RUNNING 的事务，配合 trx_query 字段确认是否卡在 DELETE 上。

避免误伤的实操建议

不要依赖“删不到就没事”的直觉。真实线上环境里，未命中的 DELETE 往往比命中的更危险：

加 LIMIT 1 能让优化器提前终止扫描，减少 Gap 锁覆盖范围（但不消除）
删除前先 SELECT ... FOR UPDATE 检查是否存在，存在再删 —— 这样锁是明确的 record lock，而非模糊的 gap
如果业务允许，把 DELETE 改成 UPDATE ... SET deleted = 1 软删，彻底避开 Gap 锁场景
对高频并发写入的间隙（如自增 ID 中间空洞），考虑降低隔离级别到 READ COMMITTED，该级别下 Gap 锁仅用于外键和唯一性检查，不用于普通 DELETE

Gap 锁的隐蔽性在于：它不保护任何真实数据，却能拦住所有想往那个空隙里写数据的操作。这点最容易被忽略，也最难排查。