read committed 是互联网高并发 oltp 场景更优默认选择，因其锁持有时间短、范围小，mvcc 快照轻量，减少阻塞与死锁；rc 每次 select 用新快照，rr 复用事务初快照；rc 无间隙锁，rr 默认启用导致范围查询易表级阻塞；rc 写后即释非匹配行锁，rr 持有临键锁至事务结束；需应用层处理不可重复读与幻读，且 binlog 格式须为 row。
READ COMMITTED 是互联网高并发 OLTP 场景下更优的默认选择，核心原因不是“它能避免脏读”，而是它让锁持有时间更短、锁范围更小、MVCC 快照生成更轻量——直接减少阻塞、降低死锁概率、提升吞吐。
RC 下每次 SELECT 都用新快照，RR 却复用事务开始时的快照
在 READ COMMITTED 级别，每个 SELECT 语句执行时，都会基于「该语句开始时刻」的最新已提交版本构建一致性视图；而 REPEATABLE READ 是整个事务只在第一次 SELECT 时建立一个快照，后续所有读都复用它。
这意味着：
- RC 中，两次
SELECT可能返回不同结果（不可重复读），但每次读都不需要维护长生命周期的快照，内存和 CPU 开销更低 - RR 中，长事务会持续 hold 住旧版本数据（undo log），可能拖慢 purge 线程，导致 history list 增长、空间膨胀
- 若应用有隐式长事务（比如 ORM 自动开启但未及时 commit），RR 更容易引发资源堆积
RC 不用间隙锁，RR 默认启用间隙锁（gap lock）
这是并发性能差异最剧烈的一点。REPEATABLE READ 为防止幻读，在范围查询（如 WHERE price > 100）或 INSERT ... SELECT 时自动加间隙锁；READ COMMITTED 则只对实际命中的记录加记录锁（record lock），不锁间隙。
后果很实际：
- 没有索引的
WHERE条件在 RR 下极易触发全表扫描 + 全表间隙锁 → 表级阻塞 - 电商库存扣减中，
UPDATE stock SET count = count - 1 WHERE sku_id = 'xxx'在 RC 下只锁匹配行；在 RR 下若sku_id无索引，可能锁住整个主键范围 - 即使有索引，RR 的间隙锁也会让相邻值插入被阻塞（例如插入
sku_id = 'xxy'被卡住），RC 完全规避
RC 对写操作的锁释放更早，减少锁等待链
READ COMMITTED 的更新类语句（UPDATE/DELETE）在语句执行完即释放非匹配行的锁；REPEATABLE READ 会将所有扫描过的记录（包括未命中 WHERE 条件的）都加上临键锁（next-key lock），并持续持有到事务结束。
典型表现：
- 一条
UPDATE users SET status = 1 WHERE created_at > '2026-05-01'在 RR 下可能锁住几千行（哪怕只更新 3 行），其他事务更新任意一行都会等 - 同样语句在 RC 下只锁最终被修改的那几行，其余扫描行锁立刻释放
- 配合短事务设计，RC 能把平均锁持有时间压到毫秒级，显著缩短
innodb_row_lock_time_avg
RC 的真实代价：你需要主动处理不可重复读和幻读
切换到 READ COMMITTED 不是“开箱即用”的性能提升，它把一部分一致性保障责任交还给了应用层：
- 不能依赖「先
SELECT再判断再UPDATE」的两次读一致 —— 中间可能已被其他事务改过 - 防超卖必须显式用
SELECT ... FOR UPDATE，且条件必须走唯一索引（如WHERE id = ?），否则仍可能幻读 - 聚合类逻辑（如「统计当前在线用户数」后做决策）需评估是否可接受瞬时偏差，否则得加应用层缓存或重试机制
最容易被忽略的是：innodb_locks_unsafe_for_binlog 必须为 OFF（默认值），否则 RC 也可能退化出间隙锁行为；主从复制务必用 ROW 格式，避免 statement + RC 下因执行顺序不同导致数据不一致。
