MySQL默认RR但生产常切RC，因RC锁更轻（仅记录锁）、快照更新及时、ROW格式下无binlog风险；RR虽通过Next-Key Lock抑制幻读，但间隙锁易阻塞写操作。
MySQL 默认用 REPEATABLE READ，但生产中很多系统（尤其是高并发互联网服务）反而主动切到 READ COMMITTED——这不是配置错误，而是权衡锁行为、MVCC 快照机制和 binlog 兼容性后的主动选择。
为什么 RR 在 MySQL 中默认却常被替换
RR 是 MySQL 历史原因定的默认值：早期主从复制依赖 STATEMENT 格式的 binlog，而 READ COMMITTED 在该格式下有数据不一致风险。如今 ROW 格式已成标配，这个限制早已解除。
但 RR 的实际代价在高并发写场景里很实在：
-
REPEATABLE READ默认启用Next-Key Lock（记录锁 + 间隙锁），哪怕你只查主键，InnoDB 也可能锁住索引间隙，导致无关插入被阻塞 - 一个
SELECT ... WHERE status = 'pending'（无索引）可能触发全表扫描+全表间隙锁，直接卡住其他事务的 INSERT -
READ COMMITTED只用Record Lock，锁更轻、范围更确定，冲突概率显著下降
RC 和 RR 的一致性读行为差异直接影响业务逻辑
关键区别不在“能不能读到新数据”，而在“什么时候生成快照”：
-
READ COMMITTED：每次SELECT都生成新ReadView，读到的是语句执行时刻最新已提交的数据 -
REPEATABLE READ：第一次SELECT时生成ReadView，后续所有查询都复用它，即使其他事务已提交修改，本事务也看不到
这意味着：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果你在事务里先查库存，再查价格，最后扣减——用 RR 能保证两次读之间数据“静止”，但可能基于过期价格做决策
- 用 RC 则每次读都是“最新快照”，更适合报表类、状态展示类接口，但要接受同一事务内两次
SELECT结果可能不同
幻读在 RR 和 RC 下的表现并不像文档写的那么绝对
SQL 标准说 RR 不解决幻读，但 InnoDB 的 RR 实际通过 Next-Key Lock 抑制了大部分幻读场景（尤其是带范围条件的 SELECT）。而 RC 因为不用间隙锁，幻读更容易发生——但这是否构成问题，得看 SQL 是否真有范围条件：
-
SELECT * FROM orders WHERE user_id = 123（有索引）→ RC 下基本不幻读，RR 下锁更重 -
SELECT * FROM logs WHERE created_at > '2026-04-01'（范围+无索引）→ RC 下极易幻读，RR 下会锁住时间范围间隙
真正要警惕的不是“有没有幻读”，而是“你的业务是否依赖两次范围查询结果稳定”。如果只是分页查列表，幻读通常可容忍；如果是“先查总数再删超限记录”，就必须锁或改逻辑。
切换隔离级别前必须验证的三件事
别只改 transaction_isolation 参数就上线：
- 确认
binlog_format是ROW或MIXED，否则READ COMMITTED可能引发主从延迟或不一致 - 检查所有
UPDATE/DELETE语句是否都命中索引，RC 下没间隙锁兜底，全表扫描等于给整张表加 X 锁 - 用慢日志或
INFORMATION_SCHEMA.INNODB_TRX观察当前锁等待情况，RR 切 RC 后若发现大量lock wait timeout消失，说明原来锁争抢就是瓶颈
最常被忽略的一点：Spring 的 @Transactional(isolation = Isolation.REPEATABLE_READ) 会覆盖全局设置，代码层显式指定的隔离级别优先级高于数据库配置。
