MySQL RR级别下死锁根本原因是临键锁必须跨行加区间锁，非唯一索引或范围查询触发间隙锁与插入意向锁互斥，形成循环等待。
MySQL 在可重复读（RR）级别下出现死锁，根本原因不是“隔离级别没设对”，而是临键锁（Next-Key Lock）在特定条件下**必须加、且必须跨行加**——它锁的从来不只是“值”，而是“值所在的区间”。
RR 下的 SELECT ... FOR UPDATE 为什么总锁住不存在的行
这是最典型的死锁诱因。RR 级别默认启用间隙锁，只要查询条件走的是**非唯一索引**或**范围条件**，InnoDB 就会用临键锁封锁“记录本身 + 后续间隙”。
- 比如表有
id主键（1, 2, 5），idx_name是普通索引，值为 ('a', 'b', 'd') -
SELECT * FROM t WHERE name = 'c' FOR UPDATE—— 'c' 不存在，但会锁住 'b' 和 'd' 之间的整个间隙 - 此时另一个事务执行
INSERT INTO t (name) VALUES ('c')，就会申请插入意向锁，与该间隙锁冲突 - 若两个事务互锁不同间隙，死锁立即触发
UPDATE 语句在 RR 下的锁范围远超你的 WHERE 条件
很多人以为 UPDATE ... WHERE col = ? 只锁匹配行，但在 RR 下，只要 col 不是唯一索引，InnoDB 就不会退化为纯记录锁。
- 唯一索引 + 精准等值查询 → 只加记录锁（Record Lock）
- 普通索引 / 非唯一索引 + 等值查询 → 加临键锁（Record + Gap），即锁住该值 + 它和下一个值之间的间隙
- 范围查询（如
WHERE col > 10）→ 锁住所有匹配行 + 最后一行之后的间隙 - 没有索引 → 全表扫描，对每个聚簇索引页都加记录锁，实际接近表锁
死锁日志里反复出现的 lock_mode X locks gap before rec 是什么
这是 InnoDB SHOW ENGINE INNODB STATUS 输出中最关键的线索，直接告诉你：当前事务正在等待一个间隙锁释放。
-
gap before rec表示锁在某条记录之前的间隙（比如前一条是 5，当前是 10，那锁的就是 (5, 10)） -
insert intention出现在 WAITING 行，说明对方正试图插入新记录，而你锁住了那个空隙 - 如果两个事务的 WAITING 行分别指向对方持有的
gap before rec位置，就是标准的环路死锁 - 注意：间隙锁之间本身是兼容的，但它和插入意向锁互斥 —— 这个设计才是死锁温床
真正难处理的不是“怎么查死锁”，而是“怎么让临键锁不加在你不想要的地方”。索引设计、查询写法、甚至业务逻辑里的幂等校验顺序，都会直接影响间隙是否被锁、被谁先锁。稍不注意，SELECT ... FOR UPDATE 就从保护变成阻塞源。
