MySQL 事务隔离级别需按业务场景选择：强一致性选可重复读或串行化，读多写少选读已提交，高并发写入慎用串行化，历史兼容性也影响选型。
MySQL 事务隔离级别不是越高越好，关键看业务场景对数据一致性、并发性能和异常容忍度的实际要求。默认的可重复读（RR）适合多数 OLTP 系统，但很多互联网项目反而更倾向读已提交（RC）。
核心交易类业务优先选可重复读或串行化
银行转账、订单支付、库存扣减等强一致性场景，必须避免同一事务内两次读取结果不一致。可重复读（RR）能保证事务中多次查询同一行数据结果恒定，即使其他事务已提交修改也不会影响当前视图。若还需杜绝幻读（比如统计 + 锁行联合校验），则需升至串行化——但要接受明显下降的并发吞吐和锁等待风险。
读多写少或分析类场景适合读已提交
报表展示、后台统计、用户中心信息页等，通常不要求单事务内绝对一致，但必须避开脏读。读已提交（RC）正好满足：它阻止了未提交数据被读取，同时允许其他事务提交后的最新值被下一次查询看到，兼顾准确性与响应速度。Oracle、SQL Server 默认用 RC，跨库兼容性也更好。
高并发写入密集系统慎用串行化
串行化通过强制加读锁 / 写锁实现完全隔离，本质是把并发事务变成排队执行。电商秒杀、抢券等场景若误配此级别，极易引发大量锁等待甚至超时。除非业务逻辑明确要求“任何时刻都只能有一个事务操作某条记录”，否则不建议启用。日常优化应优先考虑索引、语句拆分和事务粒度控制。
历史与兼容因素影响实际选型
MySQL 默认 RR 是因早期主从复制依赖 statement 格式 binlog，RC 下存在一致性风险；如今虽支持 row 格式，但切换需评估全链路影响。若系统已对接 Oracle 或使用 Spring 的 @Transactional(isolation = Isolation.READ_COMMITTED)，统一采用 RC 可减少适配成本。另外，RR 在 MySQL 中通过 MVCC + Next-Key Lock 实现，对幻读有部分抑制，而 RC 仅靠 MVCC，幻读概率更高——这点需结合具体 SQL 是否带范围条件来判断是否构成实际风险。
