应查information_schema.innodb_trx中trx_state='active'且trx_started超时的事务，而非仅看是否存在事务；开发阈值30秒、生产建议120秒起查，trx_query为空仍持锁占资源，需关联processlist定位静默挂起。
查谁在空挂事务，不是看慢查询
报错语句本身往往执行很快，真正卡住的是前面某个开了没提交的事务。别翻慢查询日志，直接查 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，线上建议阈值设为 10–30 秒 -
TRX_QUERY为空 ≠ 安全——可能是只执行了BEGIN就卡住了，锁已持有 - 比对
TRX_MYSQL_THREAD_ID和SHOW PROCESSLIST中State = 'Sleep'且Time很大的线程，基本就是它
定位谁在堵路，别杀错人
只看 INNODB_TRX 知道“谁没提交”，但不知道“谁被它堵”。必须查锁等待链：
- MySQL 8.0+：直接用
SELECT * FROM sys.innodb_lock_waits，blocking_pid字段就是该 KILL 的线程 ID - MySQL 5.7 及之前：用联查语句，注意
blocking_query为空不代表没事——可能刚执行完UPDATE就卡在应用层 HTTP 调用里了 - 真正该
KILL的是blocking_pid对应的线程，不是报错那个；杀错会导致下一个请求立刻重蹈覆辙 - 特别警惕
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或在可重复读（RR）隔离级别下执行范围查询，也会持锁
真实场景里最麻烦的不是锁本身，而是事务边界模糊导致的“隐形占用”：比如一个 Spring Service 方法里先查再发 HTTP 再更新，HTTP 卡住 2 分钟，整个事务就挂着两分钟——这期间没人知道它占着哪几行。查 INNODB_TRX 是起点，但最终得回到代码里把事务生命周期切短、加超时、显式控制 commit/rollback。
