RC比RR少加间隙锁，直接减少锁冲突；RC每次SELECT新建ReadView但开销更轻；binlog_format=ROW已成标配，RC不再有主从风险；降级前须检查“先查后更”类逻辑是否裸奔。
RC比RR少加间隙锁，直接减少锁冲突
RR级别下，InnoDB对范围查询（如 WHERE id > 100）默认使用 Next-Key Lock（记录锁 + 间隙锁），会锁住索引区间，哪怕该区间当前没数据；RC只加行锁，不加间隙锁。这意味着：
- 多个事务同时插入相邻主键值（如
id=101、id=102）时，在RR下极易因间隙重叠而互相等待，甚至死锁；RC下只要不碰同一行，就完全不冲突 -
SELECT ... FOR UPDATE或UPDATE ... WHERE带范围条件时，RR的锁范围可能远超业务需要，RC则精准锁定命中的行 - SHOW ENGINE INNODB STATUS 中频繁看到
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:开头的阻塞链，大概率是间隙锁惹的祸
RC每次SELECT都新建ReadView，但快照开销更轻
RR在事务第一次快照读时生成一个 ReadView，并复用到事务结束；RC每次 SELECT 都新建 ReadView。听起来RC更“费”，但实际更高效：
- RR的 ReadView 生命周期长，需持续跟踪所有活跃事务状态，MVCC 版本链可能拉得很长，清理（purge）线程压力大
- RC的 ReadView 是语句级的，事务一提交，相关版本就能被快速回收，undo log 回收更及时
- 高并发短事务场景（如API接口），RC的“新建”成本远低于RR的“长期持有+维护”成本
binlog_format=ROW 已成标配，RC不再有主从风险
早年RC + STATEMENT binlog 会导致主从不一致（比如先删后插，在从库串行回放变成先插后删），但现在：
- MySQL 5.7+ 默认 binlog_format=ROW，8.0+ 更是强制推荐；ROW 格式按行记录变更，与隔离级别解耦
- 执行
SHOW VARIABLES LIKE 'binlog_format';确认返回值是ROW，RC 就不会因复制机制引入一致性问题 - 若仍用 MIXED 模式，某些函数（如
NOW()、UUID()）可能退化为 STATEMENT，需额外规避
降级前必须检查“先查后更”类逻辑是否裸奔
RC允许不可重复读，最危险的是这类代码：
SELECT balance FROM account WHERE id = 123; -- 应用层判断 balance >= 100 UPDATE account SET balance = balance - 100 WHERE id = 123;
在RC下，两次操作之间，balance 可能已被其他事务扣减并提交，导致超扣。这类逻辑不能只靠隔离级别兜底，必须：
- 改用
SELECT ... FOR UPDATE显式加锁（即使在RC下，它也提供当前读+行锁） - 或合并为原子 SQL：
UPDATE account SET balance = balance - 100 WHERE id = 123 AND balance >= 100 - ORM中若用了
@Transactional且未指定isolation，要确认框架默认行为——Spring 的JpaTransactionManager默认继承连接级别，不覆盖
真正卡点不在锁或快照，而在业务代码是否隐含了“事务内读一致性”假设。这个假设一旦存在，降级RC就不是调个参数的事，而是要动逻辑。
