MySQL默认RR但多数业务应切RC：RC无间隙锁、不全表锁、ReadView实时更新，更适合高并发读多写少场景；需验证“读-判-写”逻辑并配ROW格式binlog。
MySQL默认是RR，但多数业务其实该切到RC
MySQL 5.7+ 默认隔离级别是 REPEATABLE READ（RR），但它不是“最安全就该用”的默认——而是历史包袱下的妥协。真正面向高并发、读多写少、能接受“同一事务内两次查询结果可能不同”的业务，READ COMMITTED（RC）往往更稳、更快、更少锁冲突。
- RR 下普通
UPDATE或DELETE带范围条件（如WHERE status = 1）会触发**间隙锁（Gap Lock）**，极易引发死锁；RC 下只锁实际命中的行，无间隙锁 - RR 下若查询条件未走索引，InnoDB 会升级为**全表锁**（表级意向锁 + 行锁退化），RC 下仍只锁命中行
- RC 的
SELECT每次都生成新ReadView，所以能立刻看到其他事务已提交的变更；RR 的ReadView在事务首次SELECT时就固定，后续读都基于它——这是“可重复读”来源，也是幻读残留和主从延迟放大的根源
什么时候必须坚持用RR？别被“一致性”误导
不是所有场景都能换RC。如果你的业务逻辑依赖“事务内多次读取绝对一致”，且无法通过应用层加锁或重试规避，才需要RR。典型场景包括：金融类账务核对、库存扣减前的多次校验、基于快照做幂等判断等。
- Binlog 格式必须配
ROW：RR 下若用STATEMENT，主从数据不一致风险极高（尤其涉及NOW()、UUID()、自增主键等非确定函数） - 主从复制延迟在 RR 下更难收敛：因为从库回放时也按 RR 语义重建快照，而主库新事务已推进，导致从库“看不见”刚提交的数据，表现为延迟跳变
- 使用
SELECT ... FOR UPDATE时，RR 的锁范围比 RC 大得多——哪怕你只查id = 100，RR 可能锁住(90, 110)这个间隙；RC 只锁 id=100 这一行
怎么安全地从RR切到RC？三步验证不能跳
改隔离级别不是改个配置重启就完事。生产环境切换前，必须验证应用行为是否可控。重点不是“有没有报错”，而是“逻辑是否还成立”。
- 先在测试库全局设
SET GLOBAL transaction_isolation = 'READ-COMMITTED';，再逐个连接池配置显式指定transactionIsolation=TRANSACTION_READ_COMMITTED（如 JDBC 的spring.datasource.hikari.connection-init-sql） - 跑一遍核心路径的并发压测，特别关注“读-判-写”链路：比如“查余额→判断是否足够→扣款”，在 RC 下第二次读可能看到别人刚提交的扣减，要确认你的判断逻辑是否仍成立
- 检查慢日志里有没有新增的锁等待：RC 下虽然锁粒度小，但如果应用没加索引、频繁全表扫描，
SELECT ... FOR UPDATE依然会锁大量无关行，只是不会锁间隙而已
RC下幻读还在？那是你没理解“幻读”的真实边界
很多人以为“RC 解决不了幻读，所以不如用 RR”，这是误解。幻读在 RC 和 RR 下都存在，区别在于触发条件和表现形式：
- RR 下幻读由**间隙锁失效**导致：比如
SELECT * FROM t WHERE a > 10返回空，另一个事务插入a=15并提交，当前事务再查还是空（被间隙锁拦住了）；但如果插入的是a=5，RR 下也可能看到——因为不落在原查询的间隙内 - RC 下幻读更“诚实”：只要别的事务提交了新行，且满足你的
WHERE条件，下次SELECT就能看到。这不是 bug，是 RC 的设计本意——它不承诺“结果集稳定”，只承诺“不读脏数据” - 真正要杜绝幻读，靠隔离级别没用，得用
SELECT ... FOR UPDATE+ 唯一约束 / 应用层分布式锁，或者接受“最终一致+补偿”
别把“避免幻读”当成选隔离级别的首要目标。先想清楚：你的业务能不能容忍两次读之间有新行插入？如果答案是“能”，RC 就是你该用的那个。否则，与其硬扛 RR 的锁开销，不如把逻辑搬到应用层控制。
