应查information_schema.innodb_trx中trx_state='RUNNING'且trx_started时间早、trx_query为空或执行时间超阈值（开发≥30秒、生产≥120秒）的事务，获取trx_mysql_thread_id后结合innodb_lock_waits定位真正阻塞源再KILL，而非杀报错线程。
查谁在空挂事务，不是看慢查询
报错 ERROR 1205 (HY000): Lock wait timeout exceeded 的 SQL 本身往往执行很快，真正卡住的是前面某个开了没提交的事务。别翻慢查询日志，直接查 INFORMATION_SCHEMA.INNODB_TRX：
- 运行
SELECT TRX_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY, TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) AS trx_duration_sec FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 30 - 开发环境阈值建议 30 秒，生产建议从 120 秒起查；太低会误报，太高会漏掉隐患
-
TRX_QUERY为空 ≠ 安全——可能是只执行了BEGIN就卡在应用层 HTTP 调用或日志写入里，锁已持有 - 比对
TRX_MYSQL_THREAD_ID和SHOW PROCESSLIST中State = 'Sleep'且Time很大的线程，基本就是它
定位阻塞源，不是杀报错那个线程
只看 INNODB_TRX 知道“谁没提交”，但不知道“谁被它堵”。必须查锁等待链，否则 KILL 错对象会导致下一个请求立刻重蹈覆辙：
- MySQL 8.0+：直接用
SELECT * FROM sys.innodb_lock_waits，关注blocking_pid字段，它才是该 KILL 的线程 ID - MySQL 5.7 及之前：联查
INNODB_TRX+INNODB_LOCK_WAITS，注意blocking_query为空不代表没事——可能刚执行完UPDATE就卡在 RPC 响应里了 - 特别警惕
User = 'system user'（主从同步线程）或定时任务线程，误杀可能引发主从延迟甚至数据不一致
别调大 innodb_lock_wait_timeout，它只是遮羞布
把超时从 50 秒改成 300 秒，不会让锁释放得更快，只会让失败来得更晚、更难定位：
-
SET GLOBAL innodb_lock_wait_timeout = 300只影响新连接，当前连接不受影响 - 会话级临时调低（如
SET SESSION innodb_lock_wait_timeout = 5）反而是好办法——能快速复现问题，逼出隐藏长事务 - 如果调大后错误变少，说明你掩盖了应用层事务控制缺陷，不是优化
- Spring 应用尤其常见：
@Transactional方法里调了 HTTP 或 RPC 却没设超时，或catch异常后忘了rollback
事务边界必须收口，不能靠数据库兜底
锁不是问题，不及时释放才是。ORM 默认开启事务不等于能自动收口：
- 禁止跨 HTTP 请求延续事务上下文——一个接口从头包到尾就是一个长事务，风险极高
- 所有数据库操作必须明确包裹在
BEGIN/COMMIT或等价的事务管理块中 -
AUTOCOMMIT=0的连接一旦忘了COMMIT，后续所有语句都在同一个未提交事务里累积锁 - 别依赖“我只是
SELECT”——加了FOR UPDATE或隔离级别为REPEATABLE READ时，普通SELECT也会持锁
真正卡住系统的，从来不是那条报错的 SQL，而是那个没人记得 COMMIT 的连接。查 TRX_QUERY 为空却 trx_duration_sec 过百的记录，比优化索引更紧迫。
