RC并发更高因锁范围更小：仅对命中行加记录锁，不加间隙锁，避免间隙争抢死锁；支持半一致性读跳过被锁且不满足条件的行；每次SELECT新建ReadView，降低MVCC开销。
RC不加间隙锁，锁范围小，冲突面天然窄
死锁高频发生在多个事务对同一组间隙反复争抢时。RR级别下，UPDATE WHERE age > 25 这类范围条件会自动加 Next-Key Lock（记录锁 + 间隙锁），锁住整个区间；而RC只对实际命中的行加 Record Lock，间隙不被锁定。
常见死锁链：事务A锁了 (10, 20) 间隙，事务B锁了 (20, 30)，然后都试图插入 25 → 直接卡死。RC下这个间隙没被锁，Insert Intention Lock之间天然兼容，基本不会触发循环等待。
注意：唯一索引冲突、外键约束等极少数场景，RC仍会加 Gap Lock 做校验，这点常被忽略。
RC支持半一致性读，跳过被锁但不满足条件的行
当事务A执行 UPDATE t SET x=1 WHERE y=20，扫描到某行已被事务B加了X锁时：
- RC下：先读该行最新已提交版本；若y≠20，直接跳过，不加锁也不等待
- RR下：不管是否满足条件、是否被锁，只要扫到就加
Next-Key Lock并阻塞等待
这意味着在无索引字段上做更新时，RC最终只锁住真正匹配的行；RR却可能边扫边锁所有间隙，甚至接近全表阻塞。
RC下INSERT死锁的真实诱因常被误判
很多人以为RC完全不会INSERT死锁，其实不然。关键陷阱在唯一键冲突场景——RC和RR在此类行为上完全一致：
- 两个事务并发执行
INSERT INTO users (id, email) VALUES (100,'a@b.com')，而email是唯一索引且已有同值记录 → 两者都会对已存在记录加S型Next-Key Lock，再尝试插入新行，形成X与S互斥 -
INSERT ... ON DUPLICATE KEY UPDATE在冲突时加X型Next-Key Lock，RC照常死锁 -
REPLACE INTO更激进：会在冲突记录及其下一条记录上都加Next-Key Lock
没有索引的列做唯一性判断？那会退化为全表扫描 + 大量 Record Lock，死锁风险反而更高。
RC每次SELECT新建ReadView，长事务不拖累MVCC开销
RR级别下，事务第一次 SELECT 就生成一个全局 ReadView 并复用到结束，需长期维护undo log版本链；RC每次查询都新建 ReadView，不保留事务级快照。
写多读少场景下，RC的undo log清理压力更小，版本链更短，间接降低因版本回溯引发的锁等待或超时概率。
真正复杂的地方不在“RC有没有死锁”，而在于：哪些操作看似安全，实则仍在走唯一索引冲突路径；哪些“没加索引”的WHERE条件，在RC下看似只锁行，却因全表扫描+大量Record Lock埋下隐性冲突点。
