MySQL高并发业务应优先选用READ COMMITTED而非默认REPEATABLE READ，因RC避免间隙锁、降低死锁概率、减少锁冲突，且每次SELECT新建ReadView提升Undo Log回收效率，但需校验“读-判-写”逻辑一致性。
MySQL默认用 REPEATABLE READ，但多数高并发业务不该跟着默认走——READ COMMITTED 才是更合理、更可控的起点。关键不在“要不要一致性”，而在“你是否真的需要 RR 级别的强一致性语义”。
RC 能绕开间隙锁，RR 会自动加临键锁
间隙锁（Gap Lock）和临键锁（Next-Key Lock）是 RR 级别下防止幻读的核心机制，但代价是锁范围远超实际修改行。
-
UPDATE t SET status = 2 WHERE create_time > '2026-05-01'：若create_time没索引，RR 会锁全表；有索引但范围大（比如命中 10 行），RR 可能锁住前后多个间隙，比如(2026-04-28, 2026-05-05]、(2026-05-05, 2026-05-12]……其他事务插入或更新该范围任意时间点都会被阻塞 - 同样语句在 RC 下只对实际命中的行加记录锁（Record Lock），不锁间隙；没命中就不锁，插入自由
- 死锁常见于两个事务先后执行类似范围 UPDATE，RR 下因间隙重叠极易形成循环等待；RC 下锁粒度小、冲突面窄，死锁概率显著下降
RC 的半一致性读能跳过被锁行，RR 会直接卡住
当 UPDATE 或 DELETE 扫描到某行，发现它已被其他事务加了 X 锁，RC 和 RR 的行为完全不同。
- RC：触发半一致性读（semi-consistent read），先读该行最新已提交版本；若不满足 WHERE 条件（比如
status = 1但当前已是status = 3），直接跳过，不加锁、不等待 - RR：无此优化，只要扫描到这行（无论是否满足条件、是否被锁），就尝试加临键锁，然后阻塞等待对方释放锁
- 这意味着在低效查询（如未走索引的
WHERE name LIKE '%abc%'）场景下，RR 容易把大量无关行锁住，而 RC 只处理真正要改的数据
RC 每次 SELECT 都生成新 ReadView，RR 复用首个 ReadView
MVCC 可见性判断依赖 ReadView，生成时机差异直接影响数据可见性和长事务资源占用。
- RR：事务内第一次
SELECT时生成 ReadView，之后所有快照读都复用它；即使其他事务已提交 1 小时，本事务仍看不到——这是“可重复读”来源，也是主从延迟放大的温床 - RC：每次
SELECT都新建 ReadView，立刻看到其他事务已提交变更；没有长期持有的快照，Undo Log 回收更及时，长事务对系统压力更小 - 副作用：如果你写的是
SELECT ... FOR UPDATE后再UPDATE，RC 下两次读可能看到不同数据，必须靠应用层校验或重试兜底；RR 下不会，但代价是锁更久、更宽
切到 RC 前必须验证的三个地方
改配置不是目的，验证逻辑是否还成立才是关键。别只看 SQL 是否报错。
- 检查所有“读-判-写”流程：比如先
SELECT stock判断是否充足，再UPDATE扣减。RC 下两次读可能不同，需确认是否允许中间被扣减；否则得加SELECT ... FOR UPDATE或用应用层分布式锁 - 确认 binlog 格式是
ROW：RR 下用MIXED或STATEMENT会导致主从不一致（如NOW()、自增 ID 分配）；RC 对 binlog 格式要求一样严格，但切换时容易忽略这点 - 观察锁等待指标：切换后查
information_schema.INNODB_TRX和INNODB_LOCK_WAITS，重点看TRX_WAITING和锁等待时长是否明显下降；若没变化，说明瓶颈不在隔离级别，别盲目调
最常被忽略的点是：RR 的“一致性”不是免费的，它用锁范围扩大、MVCC 快照滞留、Undo Log 积压换来的。而很多业务根本不需要跨语句的强一致性，只需要单条语句看到已提交数据——这时候坚持用 RR，等于主动给自己套上性能枷锁。
