mysql事务隔离级别对性能影响有多大_对比不同级别下的锁持有时间-mysql教程-PHP中文网

READ COMMITTED下锁持有时间更短，因仅对当前语句行加record lock且语句执行完即释放；而REPEATABLE READ默认用next-key lock并持锁至事务结束，且间隙锁易导致INSERT阻塞。

mysql事务隔离级别对性能影响有多大_对比不同级别下的锁持有时间

READ COMMITTED 下锁持有时间明显更短

在 READ COMMITTED 级别下，InnoDB 只对当前语句涉及的行加 record lock，且事务提交后立刻释放所有锁。这意味着 UPDATE 或 DELETE 语句执行完、没显式 COMMIT 前，锁只持有一条语句的时间；而 REPEATABLE READ 默认用 next-key lock（行锁 + 间隙锁），锁会一直保持到整个事务结束。

常见错误现象：UPDATE t SET status='done' WHERE id = 123 在 RR 下执行完仍卡着其他事务插入相邻 id，而在 RC 下几乎立刻放行。

RC 下：SELECT ... FOR UPDATE 和 UPDATE 的锁生命周期 = 语句执行时长 + 网络/应用层延迟
RR 下：同一事务内后续任意语句（哪怕只是 SELECT）都可能复用已有锁，锁持续时间 = 事务从 BEGIN 到 COMMIT 的全部耗时
特别注意：RR 下长事务（>30s）极易导致锁堆积，SHOW ENGINE INNODB STATUS 中 ---TRANSACTION 段能看到大量 lock struct(s) 未释放

间隙锁（Gap Lock）在 RR 下是默认开启的

间隙锁不是锁某一行，而是锁住索引中“不存在的值之间的空隙”。比如 WHERE status = 'pending' 没走索引，InnoDB 可能锁住整个 status 索引的全部间隙——新插入任何 status 值都会被阻塞。这就是为什么你没改数据、没写大 SQL，却看到 INSERT 被卡住。

READ COMMITTED 禁用间隙锁（仅保留 record lock），但有两个例外：

MySQL 8.0+ 中，**非唯一二级索引的范围查询**（如 WHERE idx_col BETWEEN 10 AND 20）仍可能加 gap lock，只为避免回表时幻读
显式使用 SELECT ... LOCK IN SHARE MODE 或 FOR UPDATE 时，gap lock 行为与 RR 一致
用 SELECT * FROM performance_schema.data_locks 查看实际锁类型：LOCK_MODE 字段含 GAP 即表示命中了间隙锁

锁等待时间暴涨往往不是 SQL 慢，而是隔离级别放大了冲突

压测时如果发现 Innodb_row_lock_waits 每秒飙升、Threads_running 长期 >32，但单条 SQL 的 EXPLAIN 显示扫描行数极少，大概率是 RR 级别下间隙锁互相卡死。

实操建议：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

用 SELECT @@transaction_isolation 确认真实生效级别，别只信 my.cnf 里的 transaction_isolation
临时降级：在应用里对非强一致场景的事务开头加 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
避免在 RR 下执行无索引的 UPDATE/DELETE，哪怕只改一行，也可能锁全表（因全表扫描触发的 next-key lock 覆盖所有间隙）
监控 History list length：超过 10000 就说明 purge 跟不上，RR 下版本链遍历开销剧增，间接拉长锁持有感知时间

binlog_format = STATEMENT 会强制降级为 READ COMMITTED

如果你开了 binlog_format = STATEMENT，MySQL 会在事务启动时自动把隔离级别降为 READ COMMITTED，否则报错 ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the statement is non-deterministic。

这意味着你配置了 transaction_isolation = REPEATABLE-READ，但实际运行中很多事务根本没走 RR —— 尤其在老系统或兼容性优先的部署里。这点常被忽略，导致调优方向完全跑偏。

验证方式：