如何处理MySQL查询中出现的“Lock wait timeout”_分析事务隔离级别-mysql教程-PHP中文网

根本原因是repeatable read默认启用间隙锁和临键锁，导致锁范围大、持有时间长；而read committed仅在唯一约束检查时加间隙锁，锁粒度更小、冲突更少。

如何处理mysql查询中出现的“lock wait timeout”_分析事务隔离级别

为什么REPEATABLE READ隔离级别更容易触发Lock wait timeout

MySQL默认用REPEATABLE READ，但它在高并发更新场景下比READ COMMITTED更易锁等待超时。根本原因不是“它更严格”，而是它默认启用间隙锁（gap lock）和临键锁（next-key lock）。比如执行DELETE FROM users WHERE status = 1且status无索引时，InnoDB可能对整个索引范围加锁，把本不该被影响的行也堵住。

而READ COMMITTED下，间隙锁仅在唯一约束冲突检查时生效，普通DML不加间隙锁，锁粒度更小、持有时间更短。

RR模式下，UPDATE t SET x=1 WHERE id > 100 AND id 会锁住(100,200)这个区间，哪怕当前没数据
RC模式下，同一条语句只锁实际命中的行，不锁间隙
RR模式下长事务+范围条件+缺失索引，极易形成“锁住一片”的局面

如何安全地临时切到READ COMMITTED

改隔离级别不能只靠SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED——这只能影响后续语句，对已开启但未提交的事务无效。真正起效的前提是：事务尚未开始，或上一个事务已COMMIT/ROLLBACK。

Java应用中常见错误是：在Spring的@Transactional方法里动态改隔离级别，结果被AOP代理忽略，还是走默认RR。

MySQL

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

下载

推荐方式：在连接池初始化时统一设置sessionVariables=transaction_isolation=READ-COMMITTED（如HikariCP的connection-init-sql）
避免在事务中调用set transaction isolation level，MySQL会报Warning且不生效
切换后需验证：执行SELECT @@tx_isolation确认返回READ-COMMITTED
注意副作用：RC下可能出现不可重复读，业务逻辑若依赖“同一事务内多次SELECT结果一致”，就得重审

查锁不能只看`INNODB_TRX`，必须连查`INNODB_LOCK_WAITS`

SELECT * FROM information_schema.INNODB_TRX只告诉你“谁在跑”，但看不出谁在等谁。真正定位阻塞源，得靠三表关联：

SELECT r.trx_id waiting_trx_id,
       r.trx_mysql_thread_id waiting_thread,
       r.trx_query waiting_query,
       b.trx_id blocking_trx_id,
       b.trx_mysql_thread_id blocking_thread,
       b.trx_query blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id
JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;

这个查询结果里，blocking_query字段常为空——因为阻塞者可能只是持有一个未提交的UPDATE，之后卡在应用层（比如远程HTTP调用没返回），SQL早就执行完了，但事务还开着。

如果blocking_query为空，重点看trx_started和trx_state：长时间RUNNING且trx_wait_started为NULL，大概率是应用没提交
trx_operation_state显示fetching rows或updating or deleting rows，说明真正在执行慢SQL，不是应用卡住
别直接KILL线程，先SHOW FULL PROCESSLIST确认Command列是不是Sleep且Time远超正常值