可通过查询information_schema.INNODB_TRX表按TRX_STARTED排序识别长事务，重点关注TRX_STATE（尤其是'LOCK WAIT'）和TRX_MYSQL_THREAD_ID，结合PROCESSLIST与INNODB STATUS分析后再谨慎KILL，根本解法是应用层控制事务超时与及时提交。
怎么查出正在运行的长事务
MySQL 的 information_schema.INNODB_TRX 表直接暴露了当前所有活跃事务，包括它们的启动时间、状态和 SQL 语句。重点看 TRX_STARTED 和 TRX_STATE 字段，而不是只盯着 TRX_ID。
- 执行
SELECT TRX_ID, TRX_MYSQL_THREAD_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED;，按启动时间排序，一眼就能看出哪些事务卡了十几分钟甚至几小时 -
TRX_STATE = 'RUNNING'不代表安全——它可能正卡在锁等待里，还没真正执行完；真正危险的是TRX_STATE = 'LOCK WAIT'，说明已陷入死锁或资源争抢 - 注意
TRX_MYSQL_THREAD_ID，这是后续KILL命令要用的 ID，不是TRX_ID
为什么不能只 kill 线程就完事
直接 KILL TRX_MYSQL_THREAD_ID 能解燃眉之急，但治标不治本。很多长事务背后是应用层没正确提交或异常退出导致的“悬挂事务”，比如 ORM 自动开启事务后忘了 commit 或 rollback，或者连接池复用时残留了未清理的事务上下文。
- 杀掉线程后，如果应用重连并继续用同样逻辑跑，问题几分钟后重现
- 某些框架（如 Django 的
atomic块、Spring 的@Transactional）在异常未被捕获时会静默挂起事务，日志里未必报错 - MySQL 8.0+ 中，
innodb_lock_wait_timeout默认是 50 秒，但应用层超时设置（如 JDBC 的socketTimeout）可能更短，导致客户端断开而服务端事务还挂着
如何避免下次再被 Lock wait timeout 报警轰炸
核心是把事务生命周期控制在应用侧，而不是依赖 DBA 手动巡检。MySQL 本身不提供“自动 kill 长事务”的开关，得靠组合策略。
- 在业务代码里给关键事务加显式超时：例如 MyBatis 的
timeout属性、JDBC URL 加connectTimeout=5000&socketTimeout=30000 - 数据库侧设硬限制：
SET GLOBAL innodb_rollback_on_timeout=ON;（5.6+ 默认关闭），让超时事务自动回滚而非卡住；同时调低innodb_lock_wait_timeout到 10–20 秒，缩短等待窗口 - 定期跑监控脚本：用
SELECT ... FROM INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60查超 1 分钟的事务，发告警而不是等报错才介入
杀事务前必须确认的三件事
别一看到 TRX_STATE = 'LOCK WAIT' 就手抖 KILL。有些事务正在做重要数据修正，强行中断可能导致数据不一致。
- 先查
SELECT * FROM information_schema.PROCESSLIST WHERE ID = TRX_MYSQL_THREAD_ID;，确认COMMAND是Sleep还是Query，以及STATE是否为Locked或空；如果是Query且INFO显示 UPDATE/DELETE，别急着杀 - 用
SHOW ENGINE INNODB STATUS\G看最近的死锁摘要，确认是不是真有冲突，还是单纯慢查询占着锁 - 检查该线程对应的业务接口是否正在被重试——比如前端反复点提交按钮，后端生成一堆并发事务互相锁死
事务卡太久不是数据库的问题，是应用没管好自己的边界。最麻烦的不是找不到长事务，而是找到之后发现它连在哪台应用服务器、哪个微服务、哪行代码里都查不到。
