事务隔离级别通过加锁策略和MVCC版本管理直接影响SELECT性能：REPEATABLE READ因复用read view和遍历长版本链增加开销；READ COMMITTED减少锁但存在幻读；SERIALIZABLE则使SELECT加共享锁阻塞写入。
事务隔离级别如何影响 SELECT 查询的性能
MySQL 的事务隔离级别不只控制数据可见性，还会直接影响 SELECT 查询的加锁行为、版本链遍历开销和缓冲池压力。读已提交（READ COMMITTED）和可重复读（REPEATABLE READ）在普通查询中差异最明显——后者默认使用间隙锁+临键锁，且每次快照读都依赖 MVCC 的一致性视图（consistent read view），该视图在事务首次 SELECT 时创建并复用，而前者每次查询都新建视图。
REPEATABLE READ 下的 MVCC 开销容易被低估
在 REPEATABLE READ 级别下，即使只是 SELECT * FROM t WHERE id = 1 这类主键等值查询，InnoDB 仍需：
- 定位到聚簇索引记录后，沿着 DB_TRX_ID 和 roll_ptr 向前遍历 undo log 版本链
- 对每个版本判断是否可见（基于事务 ID 和 read view 的 min_trx_id/max_trx_id）
- 若事务持续时间长、并发更新频繁，版本链可能很长，导致 CPU 和内存访问开销上升
常见现象：慢查询日志里没锁等待，但 EXPLAIN 显示扫描行数少、执行时间却高，此时应检查 SHOW ENGINE INNODB STATUS 中的 History list length（历史版本数）。超过 10000 就值得警惕。
READ COMMITTED 能减少锁和版本链压力，但有代价
切换到 READ COMMITTED 后：
- 每次 SELECT 都生成新 read view，避免长事务拖住旧版本
- 间隙锁（gap lock）被禁用，仅保留记录锁（record lock），降低死锁概率
- 但幻读风险真实存在；若业务逻辑隐含“两次查询结果必须一致”的假设（比如先查再 insert 防重），会出错
实操建议：
- 仅对无状态、幂等、不依赖多次读一致性的服务（如报表聚合、监控采样）启用 READ COMMITTED
- 不要全局修改 transaction_isolation，而是用 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 按需设置
- 注意：MySQL 8.0+ 中，READ COMMITTED 下的非唯一二级索引范围查询仍可能加间隙锁（为避免主键回表时幻读），这点常被忽略
Serializable 是性能杀手，除非真需要串行化
SERIALIZABLE 会让所有普通 SELECT 自动转换为 SELECT ... LOCK IN SHARE MODE，即对扫描到的每条记录加共享锁，并锁定间隙。效果等同于给整个查询范围上了读锁，阻塞所有并发写入。
SELECT * FROM orders WHERE status = 'pending';
在 SERIALIZABLE 下，这条语句可能锁住 status 索引中所有 'pending' 值对应的间隙，甚至扩展到相邻值之间——实际锁范围远超结果集。线上环境基本不用，测试或金融核心批处理中极少数场景才考虑。
真正影响性能的往往不是隔离级别本身，而是它触发的锁策略和 MVCC 版本管理方式。调优时优先看 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，再结合慢查中的 Rows_examined 和 Lock_time 判断是否由隔离级别间接导致。别只盯着 SET TRANSACTION ISOLATION，忘了应用层事务边界是否合理、是否该拆分长事务。
