MySQL默认REPEATABLE READ在高并发更新时因间隙锁导致性能下降，READ COMMITTED可提升吞吐15%~40%；SERIALIZABLE会严重降低QPS；READ UNCOMMITTED极少用于生产；基准测试需关注范围更新而非单行主键。
READ COMMITTED 和 REPEATABLE READ 在高并发更新场景下性能差距明显
MySQL 默认的 REPEATABLE READ 隔离级别在多数 OLTP 场景下不是性能最优解，尤其当表有频繁的 UPDATE 或 DELETE 且 WHERE 条件未走主键/唯一索引时，会触发间隙锁（gap lock），导致线程阻塞更久、锁等待时间上升。
实操建议：
- 确认业务是否真需要可重复读语义：如果只读事务多、写事务短且不依赖多次查询结果一致，
READ COMMITTED是更轻量的选择 - 用
SELECT @@transaction_isolation;查当前会话级别，用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;临时切换验证 - 注意 InnoDB 在
READ COMMITTED下仍使用行锁，但不加间隙锁 —— 这意味着幻读可能，但并发吞吐通常提升 15%~40%（取决于锁冲突密度） - 避免全局改隔离级别；优先在应用层按需设置，例如在 Go 的
db.Exec("SET SESSION ...")后执行关键事务
SERIALIZABLE 隔离级别几乎等于给整张表“上读锁”
SERIALIZABLE 不是“更安全的选项”，而是把所有 SELECT 自动转成 SELECT ... LOCK IN SHARE MODE，连普通查询都可能被写操作阻塞。压测中常见现象是 QPS 断崖式下跌、Waiting for table metadata lock 错误激增。
实操建议：
- 除非金融级对账等极少数场景，否则不要设为会话或全局默认值
- 若某条 SQL 真需串行化执行，显式加锁比升隔离级别更可控：
SELECT ... FOR UPDATE或INSERT ... ON DUPLICATE KEY UPDATE - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg，若开启SERIALIZABLE后这两项飙升，说明已成瓶颈
READ UNCOMMITTED 基本没人在生产用，但理解它能帮你定位脏读类问题
READ UNCOMMITTED 允许读未提交变更，看起来“最快”，实际极少用于业务逻辑 —— 因为应用层很难处理“读到一半回滚的数据”。不过它对排查某些缓存不一致或中间件重试逻辑很有用。
实操建议：
- 别把它当性能优化手段；它带来的不确定性远大于微小延迟收益
- 测试环境模拟脏读行为时可用：
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;+ 故意让一个事务UPDATE后不COMMIT，另一个去查 - ORM 框架（如 Django、MyBatis）通常不支持运行时动态设该级别，硬切需直连 MySQL 执行
SET命令
基准测试必须控制锁粒度和热点数据分布
很多“XX 级别快 20%”的结论失效，是因为测试用了单行主键更新 —— 此时四种隔离级别锁行为几乎一致；真正拉开差距的是范围更新（如 UPDATE t SET x=1 WHERE c > 100 AND c ）或非索引字段查询。
实操建议：
- 压测 SQL 必须包含真实业务模式：带范围条件的
UPDATE、多条件JOIN查询、高频更新同一张小表的多个行 - 用
sys.innodb_lock_waits视图实时看谁在等锁，比单纯看 TPS 更准 - 对比时固定
innodb_buffer_pool_size和innodb_log_file_size，否则 I/O 缓存干扰会掩盖隔离级别本身的影响 - 注意版本差异：MySQL 8.0+ 对
READ COMMITTED下的 MVCC 实现更高效，而 5.7 中部分场景反而略慢
隔离级别不是开关，是锁策略、可见性规则和日志开销的组合体。调它之前，先确认慢的是锁等待，而不是索引缺失或网络延迟 —— 后者调再低的隔离级别也没用。
