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 都生成新快照，不维持事务级一致性视图。
- 间隙锁消失 → 插入/范围查询冲突大幅下降
- MVCC 快照生命周期从“整个事务”缩短为“单条语句” → 内存和 Undo Log 压力减小
- 锁持有时间通常更短 →
innodb_lock_wait_timeout触发概率降低 - 死锁链变短 →
SHOW ENGINE INNODB STATUS中锁等待项明显减少
如何安全切换到 READ COMMITTED
切换前必须确认业务逻辑不依赖“同一事务内多次读取结果一致”这个特性。例如：订单状态校验、库存预占后二次核对等场景，若改成 READ COMMITTED，第二次 SELECT 可能读到其他事务刚提交的新值，导致逻辑错乱。
- 先在测试环境执行：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 重点验证涉及多次读+条件判断的事务（如“查余额→扣款→再查余额”）
- 上线后监控
sys.innodb_lock_waits和慢查询中type=ALL的比例是否下降 - 避免全局修改：
SET GLOBAL transaction_isolation = 'READ COMMITTED';会影响所有会话，建议按应用连接池配置或显式设置
READ UNCOMMITTED 不是性能解药，慎用
虽然它几乎不加锁、无 MVCC 开销，但允许 脏读 —— 你读到的数据可能下一秒就被回滚。真实业务中极少能接受这种风险，比如财务记账、用户积分变更、订单创建等核心路径，一旦出错无法补偿。
- 仅适用于极少数只读报表类查询，且能接受“看到未提交中间态”的场景
-
EXPLAIN显示执行计划不变，但SELECT结果不可靠，调试时容易误判数据状态 - 即使用了，也要配合
SELECT ... FOR UPDATE或显式锁来保护写路径，否则隔离性完全失控
真正影响性能的从来不是隔离级别本身，而是它触发的锁行为和 MVCC 版本链维护成本。调低级别只是手段，不是目的；最终要落到具体 SQL 是否走索引、事务是否短小、热点行是否分散这几个实操点上。
