事务隔离级别怎么影响查询速度
隔离级别越高，锁越严、并发越低、响应越慢——不是理论推论，是压测里能直接看到的 RT 上升和 QPS 下跌。比如从 READ-COMMITTED 升到 REPEATABLE-READ，InnoDB 会把间隙锁（GAP LOCK）加得更密，尤其在范围查询或 WHERE 条件没走索引时，容易卡住其他事务。
实操建议：
- 用
SELECT @@transaction_isolation确认当前会话实际生效的级别，别只信配置文件里的transaction_isolation - 压测时固定连接数（比如
sysbench --threads=64），否则高隔离级别下线程排队会掩盖真实吞吐瓶颈 -
READ-UNCOMMITTED虽快但可能读到脏数据，MySQL 官方不推荐用于业务库，仅适合日志归档类只读场景
为什么 RR 级别下 UPDATE 更容易锁表
InnoDB 在 REPEATABLE-READ 下默认启用 next-key lock（行锁 + 间隙锁），而 READ-COMMITTED 只用行锁。这意味着哪怕你只更新一行，只要 WHERE 条件涉及非唯一索引或没索引，InnoDB 就可能锁住整个索引区间。
常见错误现象：
- 执行
UPDATE t SET x=1 WHERE status='pending'时，其他事务插入status='pending'的新记录被阻塞 -
SHOW ENGINE INNODB STATUS里看到大量*** (1) WAITING FOR THIS LOCK TO BE GRANTED:，且 lock_mode 是X,GAP
实操建议：
- 给常用 WHERE 字段建唯一索引或组合索引，缩小 gap 锁覆盖范围
- 避免在 RR 级别下对大范围未索引字段做 UPDATE/DELETE，可先用
SELECT ... FOR UPDATE预热并观察锁范围 - 临时降级隔离级别：在应用层用
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED控制单个事务
压测对比必须监控的三个指标
光看平均响应时间（RT）会误判。RR 和 RC 在相同 QPS 下，RT 可能差不多，但失败率和锁等待时间天差地别。
必须盯紧：
-
Innodb_row_lock_waits：每秒增长多少？超过 5 次/秒就要怀疑间隙锁冲突 -
Threads_running：持续高于线程池设置值，说明事务卡在锁上没释放 - 慢查询日志中带
Waiting for table metadata lock或Waiting for global read lock的语句——这往往是隔离级别间接引发的 DDL 阻塞
性能影响关键点：RR 级别下，长事务会拖住 purge 线程，导致 History list length 持续上涨，最终拖慢所有 DML。
不同隔离级别对 binlog 格式有硬约束
如果开了 binlog_format = STATEMENT，MySQL 会强制将事务隔离级别降为 READ-COMMITTED，否则报错 ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the statement is non-deterministic...。这不是 bug，是 MySQL 为保证主从一致性做的限制。
实操建议：
- 主从架构下压测前先确认
binlog_format，用SELECT @@binlog_format查 - 若必须用 RR + STATEMENT，只能改用
ROW或MIXED，但ROW会显著增大 binlog 体积，影响从库重放延迟 - 云数据库（如阿里云 RDS）默认禁用
STATEMENT，直接跳过这个坑，但也要留意它背后自动切换隔离级别的行为
真正难调的从来不是选哪个级别，而是当业务代码混用多种隔离级别、又没显式开启事务时，同一张表上不同连接的锁行为会突然打架——这时候看 INFORMATION_SCHEMA.INNODB_TRX 比看文档管用。
