mysql高并发写密集场景下更优隔离级别是read committed——因其禁用间隙锁，仅对命中行加锁，降低锁冲突与死锁概率，提升qps；但需确保业务可接受不可重复读，并验证唯一约束、范围查询逻辑及应用层隔离级别设置。
MySQL在高并发写密集场景下，默认的 REPEATABLE READ 隔离级别反而容易成为性能瓶颈，真正更优的选择通常是 READ COMMITTED——前提是业务能接受不可重复读。
为什么默认的 REPEATABLE READ 在高并发下容易卡住
MySQL 的 REPEATABLE READ 为实现“可重复读”语义，会默认启用间隙锁（gap lock）和临键锁（next-key lock）。哪怕你只查主键、只更新单行，只要 WHERE 条件涉及索引范围（比如 WHERE status = 'pending' 或 WHERE id > 100），InnoDB 就可能锁住整段索引间隙。
- 现象：UPDATE 变慢、
Lock wait timeout exceeded报错频发、SHOW ENGINE INNODB STATUS显示大量事务 waiting for lock - 本质：不是锁得不够，是锁得太多、太宽、太持久
- 特别危险的是：唯一索引等值查询失败时（如查不到记录），RR 仍会加间隙锁，导致后续 INSERT 被阻塞——这和直觉完全相反
READ COMMITTED 真正的性能优势在哪
READ COMMITTED 下，InnoDB 默认禁用间隙锁（外键检查和唯一约束验证除外），只对实际命中的记录加行级记录锁（record lock），锁粒度小、持有时间短、冲突概率低。
- 写操作（UPDATE/DELETE）只锁被修改的行，不锁间隙 → INSERT 不再被无故阻塞
- 普通 SELECT 不加锁，每次读都基于最新已提交快照 → 无锁等待，QPS 更稳
- 死锁概率显著下降，尤其在
INSERT ... SELECT或批量状态更新类场景中 - Binlog 必须为
ROW格式（这是前提），否则主从不一致风险上升
切换到 READ COMMITTED 前必须核对的三件事
改配置不是改开关，而是改行为。以下三点漏掉任一，轻则逻辑错乱，重则数据异常：
- 检查应用层是否硬编码了隔离级别：比如 Spring Boot 中
@Transactional(isolation = Isolation.REPEATABLE_READ)，这种会覆盖数据库配置 - 确认关键业务是否隐式依赖“可重复读”：例如先
SELECT COUNT(*)判断是否存在，再INSERT，且没建唯一索引——RC 下可能插入重复数据 - 验证所有范围查询逻辑：如果某段代码假设“两次
SELECT * FROM t WHERE c > X结果行数不变”，那它在 RC 下会失效
最稳妥的落地方式：配置 + 初始化 SQL 双保险
只改 my.cnf 中的 transaction_isolation = READ-COMMITTED 不够，老连接不会变，ORM 也可能绕过。推荐组合动作：
- 配置文件中设置全局默认，重启后新连接生效
- 在连接池初始化 SQL 中加入：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 上线前用
SELECT @@transaction_isolation检查活跃连接的实际级别 - 监控项补上：
Com_commit/Com_rollback+ 锁等待指标，对比切前后变化
真正难的从来不是改一个参数，而是识别出哪段看似无害的“先查后插”逻辑，在 RC 下会突然开始脏插入——这类问题往往压测不爆，上线后才慢慢浮现。
