repeatable read 并非最安全或最适合高并发，read committed 在多数 oltp 场景更优，因其减少 mvcc 版本占用、加快 undo log 回收、降低锁等待率，且间隙锁才是 repeatable read 并发瓶颈的主因。
REPEATABLE READ 是 MySQL InnoDB 的默认隔离级别，但它不等于“最安全”或“最适合高并发”，实际影响必须结合具体 SQL 模式、索引设计和事务粒度来判断。盲目调高隔离级别反而可能放大锁冲突、拖慢吞吐量。
为什么 READ COMMITTED 在多数 OLTP 场景下更值得考虑
很多人默认沿用 MySQL 的 REPEATABLE READ，却没意识到它在普通更新/查询中引入了额外开销：REPEATABLE READ 要求事务启动时生成一次 MVCC 快照，并全程复用；而 READ COMMITTED 每次 SELECT 都基于最新已提交状态重建快照——这看似“不稳定”，实则减少了长事务对版本链的占用。
关键差异点：
-
REPEATABLE READ下，一个 5 秒长的只读事务会持续持有旧版本数据，阻塞 purge 线程清理 undo log，间接抬高内存与磁盘压力 -
READ COMMITTED中，即使事务持续 10 秒，每次SELECT只读取当前可见版本，undo log 回收更及时 - 对于无重复读语义依赖的业务（如用户资料页、订单列表页），
READ COMMITTED几乎零兼容成本，但可降低 15%–20% 的锁等待率
REPEATABLE READ 的间隙锁（Gap Lock）才是并发瓶颈真凶
真正让 REPEATABLE READ 在写密集场景变慢的，不是 MVCC，而是 InnoDB 默认启用的 Next-Key Lock：它同时锁定记录本身 + 记录前后的“间隙”，防止幻读。但这个机制极易引发非预期冲突。
典型踩坑场景：
- 没有索引的
WHERE条件（如UPDATE users SET status=1 WHERE name='alice'）→ 全表扫描 + 全表间隙锁 → 其他写操作全被阻塞 - 范围查询后插入（如
SELECT * FROM orders WHERE created_at > '2026-09-01'后紧接着INSERT）→ 间隙锁覆盖整个时间范围，新订单插入排队 - 唯一索引等值查询（
WHERE id = 123）不会加间隙锁，但WHERE id >= 123会 → 同样条件，写法微调就决定是否锁住后续插入
如何快速验证当前隔离级别是否拖慢你的业务
别只看 SHOW VARIABLES LIKE 'transaction_isolation'，要观察真实负载下的锁行为：
- 查锁等待：执行
SELECT * FROM performance_schema.data_lock_waits，重点看BLOCKING_TRX_ID和WAITING_TRX_ID是否高频出现 - 查间隙锁范围：开启
innodb_status_output_locks = ON，然后运行SHOW ENGINE INNODB STATUS，搜索 “lock_mode X locks gap before rec” 字样 - 对比压测结果：用
SysBench或真实流量回放，分别在READ COMMITTED和REPEATABLE READ下跑相同事务模板，重点关注transactions/sec和avg latency方差是否超过 10%
串行化（SERIALIZABLE）不是“终极保险”，而是功能开关
SERIALIZABLE 不只是“加更多锁”，它会把所有 SELECT 自动转成 SELECT ... LOCK IN SHARE MODE，相当于给读也上锁。这意味着：
- 哪怕只是
SELECT count(*) FROM logs这种只读语句，在SERIALIZABLE下也会阻塞所有对该表的INSERT/UPDATE/DELETE - 它无法规避死锁，反而因锁范围扩大更易触发（比如两个事务先后执行
SELECT ... FOR UPDATE再更新不同行） - 真正需要
SERIALIZABLE的场景极少，常见于金融核心账务的最终一致性校验环节，且通常只在单条关键语句上用SET TRANSACTION ISOLATION LEVEL SERIALIZABLE临时切换
真实并发影响从来不在“级别名称”里，而在你写的每一条 SELECT 是否命中索引、每一条 UPDATE 是否锁住不该锁的间隙、每一个事务是否在应用层保持足够短——这些细节比选哪个级别重要得多。
