如何降低MySQL事务隔离级别带来的开销

READ COMMITTED比REPEATABLE READ更轻量，因其仅用行锁、无间隙锁，每次SELECT生成新快照，锁释放快、MVCC开销小、Undo Log压力低。

直接降低事务隔离级别能显著减少锁竞争和 MVCC 开销，但必须明确：不是所有场景都适合调低，关键看业务能否容忍 不可重复读 或 幻读。对大多数 OLTP 场景，把默认的 REPEATABLE READ 改成 READ COMMITTED 是性价比最高的调整。

为什么 READ COMMITTED 比 REPEATABLE READ 更轻量

InnoDB 在 REPEATABLE READ 下会使用 Next-Key Lock（间隙锁 + 行锁），防止幻读；而 READ COMMITTED 只用行锁，且每次 SELECT 都生成新快照，不维持事务级一致性视图。

1. 间隙锁消失 → 插入/范围查询冲突大幅下降
2. MVCC 快照生命周期从“整个事务”缩短为“单条语句” → 内存和 Undo Log 压力减小
3. 锁持有时间通常更短 → innodb_lock_wait_timeout 触发概率降低
4. 死锁链变短 → SHOW ENGINE INNODB STATUS 中锁等待项明显减少

如何安全切换到 READ COMMITTED

切换前必须确认业务逻辑不依赖“同一事务内多次读取结果一致”这个特性。例如：订单状态校验、库存预占后二次核对等场景，若改成 READ COMMITTED，第二次 SELECT 可能读到其他事务刚提交的新值，导致逻辑错乱。

1. 先在测试环境执行：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
2. 重点验证涉及多次读+条件判断的事务（如“查余额→扣款→再查余额”）
3. 上线后监控 sys.innodb_lock_waits 和慢查询中 type=ALL 的比例是否下降
4. 避免全局修改：SET GLOBAL transaction_isolation = 'READ COMMITTED'; 会影响所有会话，建议按应用连接池配置或显式设置

READ UNCOMMITTED 不是性能解药，慎用

虽然它几乎不加锁、无 MVCC 开销，但允许 脏读 —— 你读到的数据可能下一秒就被回滚。真实业务中极少能接受这种风险，比如财务记账、用户积分变更、订单创建等核心路径，一旦出错无法补偿。

1. 仅适用于极少数只读报表类查询，且能接受“看到未提交中间态”的场景
2. EXPLAIN 显示执行计划不变，但 SELECT 结果不可靠，调试时容易误判数据状态
3. 即使用了，也要配合 SELECT ... FOR UPDATE 或显式锁来保护写路径，否则隔离性完全失控

真正影响性能的从来不是隔离级别本身，而是它触发的锁行为和 MVCC 版本链维护成本。调低级别只是手段，不是目的；最终要落到具体 SQL 是否走索引、事务是否短小、热点行是否分散这几个实操点上。