RC隔离级别在MySQL高并发下能提升性能，前提是业务可接受不可重复读且避免长事务和滥用SELECT ... FOR UPDATE；RC减少MVCC历史版本链维护、不加间隙锁，降低锁冲突与死锁概率。
RC隔离级别在MySQL高并发下是否真能提升性能
能，但前提是业务能接受“不可重复读”，且没滥用SELECT ... FOR UPDATE或长事务。RC比RR少维护多版本快照（MVCC）的“历史版本链”，写操作不锁间隙（gap lock），锁粒度更轻——这直接减少锁冲突和死锁概率。
常见错误现象：Lock wait timeout exceeded在RR下高频出现，切到RC后明显缓解；但若业务依赖“同一事务内多次SELECT结果一致”，切RC后逻辑就出错，这类问题上线后才暴露。
- RR默认开启
innodb_locks_unsafe_for_binlog=OFF，强制间隙锁；RC下即使该参数关闭，也天然不加间隙锁 - RC下
UPDATE/DELETE只对匹配行加记录锁，RR下还会额外加间隙锁防幻读 - binlog格式必须为
ROW，否则RC下主从数据可能不一致（语句级复制在RC下无法保证一致性）
如何安全启用RC并验证效果
不是改一个参数就完事。先确认当前事务隔离级别：SELECT @@transaction_isolation;，再分三步操作：
- 全局修改需设
transaction_isolation='READ-COMMITTED'在my.cnf中，并重启；仅会话级改用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 上线前必须压测：重点看
SHOW ENGINE INNODB STATUS\G里的TRANSACTIONS段，对比RR/RC下lock struct(s)数量和平均等待时间 - 检查慢查询日志里是否有隐式升级为RR的SQL——比如用了
SELECT ... LOCK IN SHARE MODE但没显式BEGIN，MySQL可能按会话默认隔离级别执行
RC下容易被忽略的幻读与一致性读边界
RC不解决幻读，但很多人误以为“读已提交=无幻读”。实际上，SELECT只看到事务开始前已提交的数据，而INSERT/UPDATE/DELETE仍可能因其他事务插入新行导致“幻像”。关键区别在于：RC的“一致性读”快照是语句级的，RR是事务级的。
- 执行
SELECT * FROM t WHERE id > 100;两次，中间别人插入id=105并提交，RC下第二次查询会看到它，RR下不会 -
UPDATE t SET x=1 WHERE id > 100;在RC下只锁住当前存在的匹配行；新插入的行不受影响，可能被后续相同UPDATE再次命中 - 如果业务有“先查后更”的校验逻辑（如余额扣减前查余额），RC下必须加
SELECT ... FOR UPDATE，否则校验和更新之间存在窗口期
RC与连接池、ORM框架的协同陷阱
很多Java应用用HikariCP + MyBatis，默认连接获取后不显式设隔离级别，实际沿用MySQL服务端默认值。如果DBA改了全局transaction_isolation，但应用层没同步验证，就可能出现“部分连接是RR、部分是RC”的混用状态。
- MyBatis的
<select>标签加fetchSize或useCache="false"不影响隔离级别，但flushCache="true"可能触发隐式事务，需确认是否在RC上下文中 - HikariCP的
connection-init-sql可设SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，但要注意驱动版本：MySQL Connector/J 8.0.25+才完全支持服务端返回的隔离级别名称解析 - Spring
@Transactional(isolation = Isolation.READ_COMMITTED)在JDBC驱动未正确上报时，可能降级为RR（看DataSource初始化日志里有没有Overriding isolation level警告）
最麻烦的不是配置不对，而是不同模块对“一致性”的假设不统一：有的地方靠数据库锁兜底，有的地方靠应用层重试，切RC后这些隐含契约就断了。得一行行翻业务代码里带SELECT和UPDATE的组合逻辑。
