mysql间隙锁在RR级别下的表现_如何通过主键查询避免死锁-mysql教程-PHP中文网

rr级别下主键等值查询会触发间隙锁，当且仅当目标主键值不存在时，innodb为防止幻读而在“本该存在”的位置加间隙锁；命中真实记录则只加记录锁。

mysql间隙锁在rr级别下的表现_如何通过主键查询避免死锁

RR 级别下主键查询为什么还会触发间隙锁？

MySQL 在可重复读（RR）隔离级别下，即使你用 WHERE id = 123 这种明确的主键等值查询，也可能加间隙锁——前提是这个主键值**不存在**。InnoDB 的加锁逻辑不是“看你怎么查”，而是“查到了什么、没查到什么”。如果 SELECT ... FOR UPDATE 或 UPDATE 扫描时发现目标记录不存在，它就会在“本该存在”的位置前后加间隙锁，防止其他事务插入相同主键值（即防止幻读）。

常见错误现象：Deadlock found when trying to get lock 出现在两个事务都执行 SELECT * FROM t WHERE id = 100 FOR UPDATE，而 id = 100 当前不存在。

只有 SELECT ... FOR UPDATE 或 UPDATE/DELETE 会加锁；普通 SELECT 不会
主键必须是聚簇索引（InnoDB 默认满足），且查询条件是**精确匹配主键列**（不能是函数、表达式或隐式转换）
如果主键是 INT 类型，但传入字符串 '100'，可能触发类型转换，导致走全表扫描或索引失效，进而扩大锁范围

怎么确认当前查询到底加了什么锁？

靠猜不行，得看 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（MySQL 8.0+）。最直接的方式是复现死锁后查 SHOW ENGINE INNODB STATUS，里面 LATEST DETECTED DEADLOCK 段会明确写出每个事务持有的锁和等待的锁。

MySQL 8.0 推荐用：SELECT * FROM performance_schema.data_locks，重点关注 LOCK_MODE（如 X,GAP 表示间隙锁）和 LOCK_DATA（显示间隙的边界值）
如果 LOCK_DATA 显示 100，但表里没有 id = 100 的行，基本可以断定是间隙锁卡在 (99, 101) 区间
注意：SELECT ... LOCK IN SHARE MODE 同样会加间隙锁，行为和 FOR UPDATE 一致

用主键查询避免间隙锁的三个硬条件

想让主键等值查询完全不加间隙锁，只加记录锁（Record Lock），必须同时满足：

MySQL

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

下载

查询必须命中**真实存在的记录**（不能是“查无此 ID”）
查询条件必须是**独立的主键列等值判断**，不能带 OR、不能有 IS NULL、不能和其他非主键条件组合（比如 WHERE id = 100 AND status = 1 可能导致优化器放弃主键索引）
事务中不能先执行过范围扫描（如 WHERE id > 90），否则后续对 id = 100 的操作可能被已有的间隙锁影响

示例对比：

-- ✅ 安全：id 是主键，值存在，条件干净
SELECT * FROM t WHERE id = 100 FOR UPDATE;
<p>-- ❌ 危险：id=100 不存在 → 加 (99,101) 间隙锁
SELECT * FROM t WHERE id = 100 FOR UPDATE;</p><p>-- ❌ 危险：看似主键查询，但优化器可能走错索引
SELECT * FROM t WHERE id = 100 AND deleted = 0 FOR UPDATE;</p>