MySQL 8.0+默认RR隔离级别在高并发写密集场景下易因间隙锁和临键锁导致阻塞与死锁；改用RC可减少锁冲突、提升吞吐，但需规避幻读、脏插入等风险，并确保Binlog为ROW格式及应用不依赖RR语义。
MySQL 默认隔离级别在高并发下为什么不够用
MySQL 8.0+ 默认是 REPEATABLE READ（RR），但高并发写密集场景下，它容易触发间隙锁（gap lock）和临键锁（next-key lock），导致大量事务阻塞甚至死锁。这不是 bug，是 RR 为保证可重复读语义必须付出的代价。
常见现象：UPDATE 或 SELECT ... FOR UPDATE 突然变慢、SHOW ENGINE INNODB STATUS 显示大量 waiting for table metadata lock 或 lock wait timeout exceeded；QPS 上不去，CPU 却不高——锁竞争压住了吞吐。
- RR 下即使只查主键，InnoDB 仍可能加间隙锁（比如范围查询或唯一索引等值查询失败时）
- RC（
READ COMMITTED）会禁用间隙锁（除外键和唯一约束检查外），锁粒度更细，冲突概率显著下降 - RC 不支持“可重复读”，但多数业务（如订单创建、库存扣减、日志写入）根本不需要该语义——它们只关心自己提交那一刻的数据一致性
如何安全地把 MySQL 切到 RC 隔离级别
不能只改全局变量，否则已有连接不受影响，且应用层事务行为可能意外变化。关键是要让新连接默认使用 RC，并确保应用逻辑不依赖 RR 特性。
- 修改配置文件
my.cnf，在[mysqld]段添加：transaction_isolation = READ-COMMITTED
- 重启 MySQL 或执行
SET GLOBAL transaction_isolation = 'READ-COMMITTED';（注意：已存在的连接仍保持原隔离级别） - 应用启动时显式设置会话级隔离级别更稳妥，例如在连接池初始化 SQL 中加入：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
- 务必检查 ORM 是否硬编码了隔离级别（如 Spring 的
@Transactional(isolation = Isolation.REPEATABLE_READ)），否则配置无效
RC 下哪些操作要特别小心
RC 解除了大部分间隙锁，但也带来两个典型风险点：不可重复读、幻读暴露。不是所有业务都能忽略。
-
SELECT ... FOR UPDATE在 RC 下只锁命中的行，不锁间隙 —— 如果业务靠“先查再插”防重复（如唯一约束未建好），可能产生脏插入 - 幻读真实发生：事务 A 查出 10 条记录，事务 B 插入 1 条并提交，A 再查可能看到 11 条；若业务逻辑依赖“两次查询结果一致”，RC 会打破它
- RC 下
UPDATE语句的 WHERE 条件若走不到索引，会升级为全表扫描 + 行锁，锁住所有行 —— 这比 RR 下的间隙锁更危险，因为锁更多、持续时间更长 - Binlog 格式必须是
ROW（binlog_format = ROW），RC + STATEMENT 格式在主从复制中可能出错
RC 性能提升到底体现在哪几个地方
提升不是来自“更快的 SQL 执行”，而是更少的锁等待、更低的锁管理开销、更高的并发容忍度。
- 锁数量下降：RC 下普通
SELECT不加锁，UPDATE/DELETE只锁实际修改的行，无间隙锁开销 - 死锁概率降低：间隙锁是 MySQL 死锁主因之一，RC 去掉它后，死锁多发生在纯行锁竞争，更容易被检测和回滚
- 锁等待时间缩短：相同负载下，
innodb_row_lock_time_avg通常下降 30%~70%，尤其在热点行更新场景（如计数器、余额字段） - 注意：RC 对只读查询性能几乎无影响；真正受益的是写多读少、高并发更新的 OLTP 场景
最常被忽略的一点：RC 不是银弹。如果业务用了乐观锁（version 字段）或应用层重试机制，RC 的优势会被放大；但如果业务强依赖“同一个事务里多次读取结果不变”，那切 RC 就得同步重构逻辑，而不是只调个配置。
