MySQL主从复制下推荐READ COMMITTED隔离级别，前提是binlog_format=ROW；RC更轻量、降低死锁概率、读取最新提交数据更符合业务直觉，且在ROW模式下与RR主从一致性无差异。
MySQL主从复制模式下建议将隔离级别设为 READ COMMITTED，前提是 binlog 格式已改为 ROW（这是 5.1+ 版本默认且强烈推荐的配置）。RC 不是“更安全”，而是更轻量、更可控、更贴合现代业务逻辑——尤其在高并发写场景下。
RC + ROW binlog 能彻底规避主从不一致的根源
主从不一致的元凶从来不是 RC 本身，而是 STATEMENT 格式 binlog 与 RC 的组合：STATEMENT 只记 SQL 文本，RC 下事务内多次读可能看到不同快照，导致主库执行顺序和 binlog 记录顺序错位。而 ROW 格式记录的是“哪几行被改了、改成什么样”，完全脱离 SQL 执行上下文。只要 binlog 是 ROW，RC 和 RR 在主从一致性上没有任何区别。
-
binlog_format = ROW是前提，必须确认（SELECT @@binlog_format;） - RC 下不会因间隙锁阻塞插入，降低死锁概率
- RC 下
UPDATE/DELETE语句只锁实际命中的行，不锁间隙；RR 会加Next-Key Lock，容易锁表或锁住不该锁的范围
RC 的一致性读行为更符合直觉和业务预期
RC 每次 SELECT 都基于最新已提交版本生成 ReadView，意味着你总能读到其他事务刚提交的数据。这对订单状态变更、库存扣减、消息幂等校验等场景很关键——RR 的“事务内快照不变”反而容易掩盖数据已更新的事实。
- 例如：下单事务中先查库存（读到 10），再扣减（UPDATE SET stock = 9）；若另一事务此时提交了补货（stock = 15），RC 下第二次查能立刻看到 15，RR 下仍看到旧值 10
- RC 下不会出现“幻读被误判为业务异常”的情况（比如分页查询两次结果条数不一致，但这是正常现象，不是 bug）
- Oracle、PostgreSQL 默认都是 RC，开发者心智模型更统一
RR 的间隙锁在主从场景中反而成负担
RR 引入间隙锁本质是为堵住 STATEMENT binlog 下的主从漏洞，但在 ROW 模式下这个补丁已无必要。它带来的副作用却真实存在：
- 条件未走索引时，RR 会升级为全表锁（
SELECT ... FOR UPDATE或UPDATE无索引 WHERE）；RC 仅锁匹配行 - 高并发 INSERT 场景下，RR 的间隙锁极易引发死锁，尤其是自增主键 + 范围条件混合使用时
- 监控发现
Innodb_row_lock_waits持续升高，大概率是 RR 下间隙锁争用所致
真正容易被忽略的是：是否所有从库都和主库用了相同的 binlog_format？哪怕主库是 ROW，某个从库被误设为 STATEMENT，RC 就会重新暴露不一致风险。上线前务必逐台验证 SHOW VARIABLES LIKE 'binlog_format';。
