必须改默认REPEATABLE READ的情况有三种：一是业务需每次读最新提交数据（如风控校验），须切READ COMMITTED；二是范围查询+频繁插入引发高死锁，可降级READ COMMITTED减少间隙锁；三是低一致性要求报表任务，可临时用READ UNCOMMITTED（需独立连接并注释）。
REPEATABLE READ 是 MySQL InnoDB 的默认隔离级别，大多数业务场景下直接使用它即可，不需要刻意调整。但如果你遇到幻读、不可重复读或性能瓶颈，才需要主动评估和切换。
什么时候必须改默认的 REPEATABLE READ？
不是“要不要换”，而是“有没有被逼到非换不可”——通常只有以下几种情况才值得动：
- 业务逻辑明确要求“每次
SELECT都看到最新已提交数据”，比如实时计数器、风控规则校验，此时REPEATABLE READ会因复用 Read View 导致读不到其他事务刚提交的变更，得切到READ COMMITTED - 大量范围查询 + 频繁插入，且应用层没做防幻读处理（如
SELECT ... FOR UPDATE加间隙锁），导致死锁率飙升，这时降级到READ COMMITTED可减少间隙锁争用 - 极低一致性要求的报表类任务（如小时级汇总），允许脏读，可临时设为
READ UNCOMMITTED，但必须用独立连接、明确注释，不能污染主业务链路
READ COMMITTED 真的比 REPEATABLE READ “更安全”吗？
不。它只是把问题暴露得更早、更频繁：
-
READ COMMITTED每次SELECT都生成新 Read View，所以能读到其他事务刚提交的数据，解决了不可重复读，但幻读依然存在（InnoDB 不在该级别自动加间隙锁） - 它不会“防止”幻读，只是让你更容易发现幻读——比如同个事务里两次
SELECT COUNT(*)结果不同，你得自己加SELECT ... FOR UPDATE或改用REPEATABLE READ - 在高并发更新场景下，
READ COMMITTED的 MVCC 版本链更长，可能略微增加 undo log 清理压力，尤其当长事务频发时
怎么验证当前会话的隔离级别生效了？
别只信配置文件或启动参数，运行时确认才可靠：
- 执行
SELECT @@transaction_isolation;，返回值必须是全大写带短横线的格式，例如'READ-COMMITTED'（注意不是READ COMMITTED） - 如果用的是连接池（如 HikariCP、Druid），要确认连接获取后是否显式设置了隔离级别——很多池子默认复用连接的 session 状态，
SET SESSION TRANSACTION ISOLATION LEVEL ...只对当前会话有效，下次从池取连接可能还是旧值 - ORM 框架（如 MyBatis、SQLAlchemy）可能在事务开启时覆盖隔离级别，比如 Spring 的
@Transactional(isolation = Isolation.READ_COMMITTED)才真正起效，单纯配数据源参数无效
生产环境最容易被忽略的点
隔离级别不是单点开关，它和锁、MVCC、binlog 格式、主从复制模式深度耦合：
- 如果开了
binlog_format = STATEMENT，又用了READ COMMITTED，某些非确定性函数（如NOW()、UUID()）在主从间可能产生不一致——因为从库重放时时间戳不同 -
REPEATABLE READ下，INSERT ... SELECT会隐式加临键锁，而READ COMMITTED只加记录锁，这直接影响并发插入性能和死锁概率 - 跨库事务（如分库分表中间件）根本不支持真正的
REPEATABLE READ，因为无法协调多个物理库的 Read View，此时谈隔离级别意义不大，得靠应用层补偿
