生产环境建议将MySQL隔离级别从RR切到RC，核心原因是RR在高并发写场景下因间隙锁导致大量无关锁冲突，而RC仅锁定实际读取或修改的行，减少死锁和锁等待，提升并发性能。
生产环境建议将 MySQL 隔离级别从 REPEATABLE READ（RR）切到 READ COMMITTED（RC），核心原因不是“RC 更先进”，而是 RR 在高并发写场景下会凭空多出大量锁冲突，而这些锁多数跟业务逻辑无关——比如你只查 id = 100，RR 却可能锁住 (95, 105] 这个间隙，导致其他事务往这个范围插入数据时被卡住。
RR 的间隙锁在无索引查询时直接升级为全表锁
这是最常踩的坑：当 WHERE 条件没走索引，RR 下 InnoDB 会退化为对整个聚簇索引加间隙锁，实际效果接近表级阻塞。
-
SELECT * FROM orders WHERE status = 'pending'（status无索引）→ RR 锁全表间隙，新订单插入全部排队 - 同样语句在 RC 下只锁命中的行（如果有的话），没命中就不锁，插入完全不受影响
- 即使有索引，范围查询如
WHERE create_time > '2026-06-01'在 RR 下也会锁多个间隙；RC 仍只锁实际更新/读取的行
RC 每次 SELECT 都新建 ReadView，但代价是应用必须接受“读-判-写”结果不一致
RR 的“可重复读”本质是复用第一个 SELECT 生成的 ReadView，RC 则每次查都看最新已提交数据。这看似削弱一致性，实则更贴近现实业务节奏。
- 报表类接口、状态页展示、搜索列表——要的就是“此刻真实值”，RC 天然适配
- 但像“查余额 → 判断是否 ≥100 → 扣减”这种链路，RC 下第二次读可能看到别人刚扣完的余额，你的判断就失效了
- 这类逻辑不能靠隔离级别兜底，得加
SELECT ... FOR UPDATE或应用层校验重试
死锁和锁等待在 RR 下更频繁，尤其范围 UPDATE/DELETE 场景
两个事务执行相似的范围操作（比如都按时间删日志），RR 因间隙重叠极易形成循环等待；RC 只锁实际行，冲突面窄得多。
UPDATE logs SET processed = 1 WHERE created_at BETWEEN '2026-06-01' AND '2026-06-07'- RR：两个事务各自锁住自己扫描到的行 + 前后间隙 → 间隙重叠 → 死锁概率飙升
- RC：只锁命中的行，且扫描时遇到被锁行会触发半一致性读（
semi-consistent read），跳过不满足条件的已锁行，不加锁也不等 - 慢日志里
Lock wait timeout exceeded或Deadlock found频发，先查是不是 RR 下的间隙锁在作祟
真正难的不是改配置，而是确认哪些 SQL 真正依赖“事务内多次读绝对一致”。金融核对、库存预占、幂等判断这类场景才需要 RR；其余绝大多数读多写少、能容忍短暂不一致的服务，RC 是更轻、更稳、更少意外的选择。别忘了同步检查 binlog_format 必须是 ROW，否则切换 RC 后主从可能出问题。
