DELETE 精确命中主键，在被删除后，其行锁是不是会退化为间隙锁，阻塞后续插入？

## **是的，在特定条件下，会。** ### 场景解释： 1. 某事务 A： ```sql BEGIN; DELETE FROM t WHERE id = 5; -- 命中主键 ``` 2. 此时 InnoDB 加的是记录锁（Record Lock）在 `id=5` 上。 3. **但记录尚未物理删除（未 commit）**，此时另一个事务 B： ```sql INSERT INTO t (id, name) VALUES (6, 'xxx'); -- 被阻塞 ``` 4. **原因：InnoDB 为了防止“插入复活”已删数据，保留锁语义** * 被 delete 的记录在事务提交前仍存在 → INSERT 被阻塞 * 提交后，该锁**变成间隙锁，锁住原来 id=5 的位置** ## 特别的“锁继承”逻辑 * **记录删除后，该记录锁不能简单释放**，否则并发事务可能插入重复的主键； * 因此，**该记录锁转化为 gap lock**，继续锁住 `id=5` 的插入位置直到事务结束； * 这是 **InnoDB 的锁继承机制**的一种体现。 ## 举个简单例子验证 ```sql -- 事务 A BEGIN; DELETE FROM user WHERE id = 5; 如果5是最大值，那间隙锁的范围是(4, ∞) -- 此时，事务 B： INSERT INTO user (id, name) VALUES (6, 'blocked'); -- 被阻塞 -- 即使事务 A 精确命中 DELETE，也导致 B 阻塞 ``` ## 总结一句话： > **DELETE 精确命中主键，在记录未提交删除期间持有行锁，提交后锁会转化为间隙锁，继续锁住插入点。** > 所以 yes：确实会“退化”为间隙锁，用于保持隔离语义完整。