RR隔离级别下更容易死锁，因其强制使用Next-Key Lock引入Gap Lock，导致并发插入时因Insert Intention Lock与Gap Lock互斥而形成循环等待；RC默认不加间隙锁，仅锁实际行，冲突更少。
RR 隔离级别下更容易死锁，核心原因是 Next-Key Lock（临键锁）强制引入了 Gap Lock（间隙锁），而 RC 默认禁用 Gap Lock，锁范围更小、冲突更少。
RR 下的间隙锁允许并发持有但互斥插入意向锁
在 RR 级别中，SELECT ... FOR UPDATE 或 UPDATE 执行范围条件（如 WHERE id BETWEEN 10 AND 20）或查询不存在的记录（如 WHERE id = 5 但无该行）时，InnoDB 不仅锁住匹配的行，还会锁住索引间隙，比如 (3, 8)。
关键点在于：多个事务可以同时在同一个间隙上持有 Gap Lock（它们不互斥），但当各自尝试插入新记录时，都需要申请与 Gap Lock 互斥的 Insert Intention Lock——这就触发了双向等待：
- T1 持有间隙
(3, 8)的 Gap Lock，等待 T2 释放该间隙上的 Insert Intention Lock - T2 同样持有同一间隙的 Gap Lock，也在等待 T1 释放
循环等待形成，InnoDB 检测到后回滚其中一个事务，报错 Deadlock found when trying to get lock (Error 1213)。
RC 级别默认不加间隙锁，只锁实际存在的行
RC 下，SELECT ... FOR UPDATE 和普通 UPDATE 语句只对真实命中索引的记录加 Record Lock；对不存在的记录，不加任何锁。
这意味着：
- 两个事务同时执行
SELECT * FROM t WHERE id = 5 FOR UPDATE（id=5 不存在），都返回空结果，且都不加锁 - 后续各自
INSERT INTO t VALUES (5)时，只竞争主键/唯一索引上的排他锁，不会陷入间隙层面的循环等待 - 即使发生锁等待，也是单向的（比如后插入者等前插入者提交），不会构成死锁
例外情况仅出现在唯一索引冲突检查中（如插入重复唯一值），此时仍需 Gap Lock 防止其他事务插入相同值——但这属于防御性加锁，非普遍行为。
RR 中缺失索引或全表扫描会放大锁粒度
RR 下若 WHERE 条件未命中索引，InnoDB 可能退化为锁全表（准确说是锁聚簇索引所有记录 + 所有间隙），而 RC 在这种场景下仍只锁实际扫描并命中的行（配合 semi-consistent read 机制提升 update 并发）。
常见踩坑点包括：
- 更新语句用了
OR、函数、隐式类型转换，导致索引失效 - 联合索引未按最左前缀使用，造成范围扫描扩大
- 业务误用
SELECT ... FOR UPDATE锁大量无关记录，再做后续判断
这些在 RR 下会把 Gap Lock 范围拉得极大，显著提高多事务交叉加锁概率。
死锁不是配置问题，而是锁行为差异的必然结果
真正容易被忽略的是：死锁频发往往不是因为“事务顺序写错了”，而是开发人员没意识到 RR 下一条看似简单的 UPDATE 实际锁住了多大一片索引空间。你查 SHOW ENGINE INNODB STATUS\G 里的 LATEST DETECTED DEADLOCK 区块，十次里有八次能看到 Gap Lock 和 Insert Intention Lock 同时出现。
如果业务能接受不可重复读（比如订单状态流转、消息消费、计数类场景），切换到 RC 是见效最快的方式；若必须用 RR，则必须严格保证所有写操作走有效索引，并避免长事务拖慢 purge 线程，否则 undo 版本链膨胀也会间接加剧锁竞争。
