当前位置：首页 > news >正文

事务与锁的进阶实战：读懂死锁日志之外的锁等待链

news 2026/7/22 15:35:05

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

前几周我们讲了死锁排查——怎么读SHOW ENGINE INNODB STATUS、怎么从日志里找到两个冲突的事务。但死锁只是锁问题的“冰山一角”。

死锁会直接报错，你一眼就能看到。但真正让系统“卡住”的，往往是那些不报错、不告警、只默默等待的锁等待问题。

一条SQL平时0.1秒，今天突然3秒。执行计划没变、索引没坏、数据量也没暴涨。你翻遍慢查询日志找不到原因——问题可能不在SQL本身，而在它“等锁”了。

今天把锁等待的排查方法彻底拆开讲一遍。

一、死锁 vs 锁等待：两种截然不同的锁问题

先搞清楚这两个概念的区别：

死锁（Deadlock）：两个事务互相持有对方需要的锁，形成循环等待。数据库检测到后会主动回滚其中一个事务，报Deadlock found错误。特点是“报错”——DBA能直接看到。

锁等待（Lock Wait）：一个事务在等另一个事务释放锁，但另一个事务还在正常执行，没有形成循环。被阻塞的事务会一直等，直到超时（innodb_lock_wait_timeout默认50秒）。特点是不报错——业务只是变慢，没有错误日志。

死锁是“急诊”——需要立即处理。锁等待是“慢性病”——它不会一下子让系统崩溃，但会让系统越来越慢，而你很难找到病根。

二、锁等待的三种典型场景

场景一：长事务持有锁不释放

一个事务执行了UPDATE但没有提交，然后去调用外部API、做复杂计算、或者等用户输入。在此期间，它持有的锁一直不释放，其他事务全部被阻塞。

场景二：大事务分批执行不当

一个事务里包含了大量操作——比如一次性更新100万行。事务执行期间，锁一直持有，其他事务被长时间阻塞。

场景三：热点行竞争

多个事务同时操作同一行数据（比如秒杀场景下的库存扣减）。虽然每个事务都很快，但高并发下锁等待时间叠加，整体响应变慢。

三、锁等待排查的核心工具

工具一：SHOW ENGINE INNODB STATUS

这个命令除了显示死锁信息，还会显示当前的锁等待情况。在LATEST DETECTED DEADLOCK之后，还有一个TRANSACTIONS部分，会列出当前所有活跃事务及其持有的锁。

SHOW ENGINE INNODB STATUS\G

找到TRANSACTIONS部分，重点关注：

ACTIVE时间——事务活跃了多久
LOCK WAIT——是否在等待锁
HOLDS THE LOCK(S)——持有哪些锁
WAITING FOR THIS LOCK——在等哪个锁

工具二：INFORMATION_SCHEMA.INNODB_TRX

这是最常用的锁等待监控视图。它显示当前所有活跃事务的详细信息：

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query, trx_rows_locked, trx_rows_modified, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_duration_sec FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' ORDER BY trx_started;

关键字段解读：

字段	含义	诊断价值
`trx_started`	事务开始时间	判断是否长事务
`trx_rows_locked`	锁定的行数	锁范围有多大
`trx_rows_modified`	修改的行数	事务大小
`trx_query`	当前执行的SQL	定位具体操作

工具三：INFORMATION_SCHEMA.INNODB_LOCK_WAITS

这个视图直接显示谁在等谁：

SELECT * FROM information_schema.INNODB_LOCK_WAITS;

输出中包含requesting_trx_id（等待的事务）和blocking_trx_id（阻塞的事务），可以直接看出锁等待链。

四、锁等待链的完整排查流程

第一步：找出所有在等待锁的事务

SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';

第二步：找出谁在阻塞它们

SELECT waiting_trx_id, waiting_thread, blocking_trx_id, blocking_thread FROM sys.innodb_lock_waits;

schema是MySQL 5.7+自带的系统库，比直接查INFORMATION_SCHEMA更方便。

第三步：检查阻塞事务在做什么

拿到blocking_trx_id后，回到INNODB_TRX查看该事务的详细信息：

SELECT trx_id, trx_started, trx_query, trx_rows_locked, trx_rows_modified FROM information_schema.INNODB_TRX WHERE trx_id = 'blocking_trx_id';

第四步：判断阻塞事务是否可以终止

如果事务活跃时间很长（>10秒）且一直没有提交 → 可能是应用代码忘记提交或回滚
如果事务正在执行一个很慢的SQL → 可能需要优化该SQL
如果事务处于SLEEP状态 → 可能是连接池中的空闲连接持有锁

第五步：决定处理方式

如果阻塞事务是“僵尸事务”（应用已经断开但事务未提交）→ 执行KILL终止该连接
如果阻塞事务是正常业务但执行时间过长 → 优化SQL或拆分事务
如果阻塞事务是热点行竞争 → 考虑优化业务逻辑或使用乐观锁

五、实战案例：一个真实的锁等待排查

现象：某电商系统下午3点开始，订单创建接口响应时间从200ms飙升到3秒，持续了20分钟后自动恢复。

排查过程：

查看INNODB_TRX，发现有13个事务处于LOCK WAIT状态
通过sys.innodb_lock_waits找到阻塞者：一个事务ID为310298的事务
查看该事务信息：trx_started是25分钟前，trx_rows_modified=5000，trx_query=NULL
该事务处于SLEEP状态，说明应用已经断开了连接，但事务没有提交或回滚

根因：应用代码中有一个@Transactional注解的方法，内部调用了外部API。外部API超时导致方法异常退出，但事务没有回滚，锁一直持有。后续所有操作同一行数据的请求全部被阻塞。

解决方案：事务中不调用外部API，将外部调用移到事务外。或者在@Transactional中设置超时时间。

六、锁等待对系统性能的“隐性影响”

锁等待不像死锁那样“显眼”，但它对系统性能的影响可能更大：

影响一：响应时间线性增加

一个查询本身0.1秒，但等锁等了0.5秒，总响应时间变成0.6秒。如果每秒有100个这样的查询，系统整体响应时间就会明显变慢。

影响二：连接池耗尽

大量请求被阻塞等待锁，连接池中的连接被占用但无法释放。新请求无法获取连接，业务直接报错。

影响三：连锁阻塞

一个长事务阻塞了10个请求，这10个请求又各自持有其他锁，阻塞了更多请求——形成连锁反应。

七、锁等待的预防策略

1. 监控长事务

建议设置阈值告警：事务活跃时间超过10秒自动告警。虽然long_query_time无法覆盖事务场景（SQL已经执行完但事务未提交，慢查询日志不会记录），但可以用INNODB_TRX定期扫描实现告警。

-- 每10秒执行一次，检测活跃超过10秒的事务 SELECT trx_id, trx_started, trx_mysql_thread_id, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 10;

2. 拆分长事务

避免在一个事务中处理大量数据。将大事务拆分为多个小事务，每批处理一部分数据并提交。

3. 事务中不调用外部API

事务中调用外部API是不可控的——外部API可能超时、可能报错、可能响应很慢。在外部API返回之前，事务持有的锁一直不释放。正确做法是：外部调用放在事务之前或之后，事务内只做数据库操作。

4. 设置合理的锁超时

MySQL的innodb_lock_wait_timeout默认50秒。如果业务对响应时间敏感，可以适当降低这个值，让被阻塞的事务更快失败，而不是长时间等待。

八、总结

锁等待是比死锁更隐蔽、更难发现的性能问题。它不报错、不告警，只默默让系统变慢。

排查锁等待的核心工具：