mysql默认隔离级别是repeatable read（rr），它通过mvcc和next-key lock保证同一事务内多次读取结果一致，避免脏读和不可重复读，但幻读仍可能发生；read committed（rc）每次select新建快照，可读已提交数据，性能更好但存在不可重复读，需应用层补偿。
确认当前事务是否依赖RR的“可重复读”语义
很多业务代码隐式假设了 REPEATABLE READ 下同一事务内多次 SELECT 返回一致结果。比如库存扣减前查两次余额、风控系统中多次校验用户状态。一旦切到 READ COMMITTED，第二次查询可能看到其他事务刚提交的变更，导致逻辑错乱。
实操建议：
- 搜索代码中所有跨多条
SELECT+UPDATE的事务块，尤其关注“先查后判再改”的模式 - 检查是否有类似
if (select count(*) > 0) then update ...这类非原子判断逻辑 - 用慢日志或
performance_schema.events_statements_history_long抽样分析长事务里重复读取的表和条件
验证幻读是否实际影响核心业务逻辑
REPEATABLE READ 能在多数场景下阻止幻读（靠间隙锁+Next-Key Lock），而 READ COMMITTED 默认不加间隙锁，只锁命中的行。这意味着：另一个事务插入符合你 WHERE 条件的新行并提交后，你事务内再次执行相同 SELECT 就会看到新行——这就是幻读。
但不是所有幻读都致命。实操建议：
- 重点看带范围条件的查询，如
SELECT * FROM orders WHERE status = 'pending' AND created_at > '2026-10-01' - 检查这类查询是否用于生成报表、对账、或者作为后续
UPDATE ... WHERE的依据 - 在测试环境开启
innodb_locks_unsafe_for_binlog=OFF（MySQL 5.7+ 已废弃，但需确认版本）并模拟插入，观察应用层是否崩溃或重复处理
检查是否绕过事务直接依赖快照一致性
有些服务把“事务开始时刻的全局快照”当成了事实依据。例如订单服务启动时读一次配置表，缓存整个事务生命周期；或者分库分表中间件基于 RR 快照做路由决策。这类设计在 RC 下会失效——每次查询都拿最新已提交快照，不再是事务起点快照。
常见风险点：
- 使用
SELECT ... FOR UPDATE但没配合WHERE条件锁定具体行，误以为能锁住范围 - 依赖
SELECT @@transaction_isolation判断行为，却没意识到 RC 下SELECT不阻塞INSERT - ORM 框架（如 Django 的
select_for_update()或 MyBatis 的FOR UPDATE）在 RC 下仅锁行，不锁间隙，需额外加SELECT ... LOCK IN SHARE MODE或业务层重试
性能提升与死锁概率必须实测对比
RC 的核心收益是减少间隙锁，降低死锁率、提升并发写入吞吐。但这不是免费的——它把部分一致性保障交给了应用层。不能只看理论，要压测。
关键动作：
- 在预发环境用相同流量回放，对比
SHOW ENGINE INNODB STATUS中的deadlocks计数 - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg，RC 通常下降明显，但若业务大量INSERT ... SELECT，可能反而增加锁等待 - 特别注意外键约束和唯一索引冲突场景：RC 下
INSERT失败后重试逻辑是否健壮，RR 下可能因快照不变而重试成功，RC 下可能持续失败
真正难评估的从来不是“能不能切”，而是“哪些地方切了之后没人报错，但数据已经不对了”。尤其是那些没有显式事务标记、靠连接生命周期自动提交的查询，最容易在 RC 下暴露隐含依赖。
