事务隔离级别如何影响 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，忘了应用层事务边界是否合理、是否该拆分长事务。
