如何在MySQL中监控长达数小时未关闭的事务连接？-mysql教程-PHP中文网

查information_schema.innodb_trx是最直接手段，通过trx_started时间戳可精准识别长事务，结合trx_state='running'和trx_query为null可判断事务空转挂起，须关联processlist确认线程真实状态。

如何在mysql中监控长达数小时未关闭的事务连接？

查 `information_schema.INNODB_TRX` 是最直接的手段

长事务不会自动“标记自己”，但 INNODB_TRX 表里有唯一可靠的线索：trx_started。它记录事务真正开始的时间，不是连接建立时间，也不是 SQL 执行起点——而是 BEGIN 或第一条 DML 触发的那一刻。

执行这个查询就能揪出卡住几小时的事务：

SELECT 
  trx_id,
  trx_mysql_thread_id AS thread_id,
  trx_started,
  TIMESTAMPDIFF(HOUR, trx_started, NOW()) AS duration_hours,
  trx_state,
  trx_query
FROM information_schema.INNODB_TRX 
WHERE TIMESTAMPDIFF(HOUR, trx_started, NOW()) >= 1
ORDER BY trx_started ASC;

用 HOUR 而不是 SECOND，避免数字过大干扰判断；阈值设为 1 小时，比秒级更贴合“数小时”场景
trx_state = 'RUNNING' 不代表正在跑 SQL，很可能是应用层拿了连接没提交，处于挂起状态
如果 trx_query 是 NULL，基本可断定事务已空转，只等 COMMIT/ROLLBACK
注意别只看 duration_hours > 0，要结合业务预期——有些批处理本就该跑 2 小时，重点是“非预期的长时间空转”

必须联查 `PROCESSLIST` 才能确认是否真“活着”

INNODB_TRX 显示事务存在，PROCESSLIST 才告诉你这个线程现在在干啥。两者不一致是常态，尤其在连接池场景下。

运行这条语句对齐两者：

MySQL

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

下载

SELECT 
  t.trx_id,
  t.trx_mysql_thread_id,
  p.ID AS processlist_id,
  p.USER,
  p.HOST,
  p.COMMAND,
  p.TIME AS processlist_time,
  p.STATE,
  p.INFO AS current_sql
FROM information_schema.INNODB_TRX t
JOIN information_schema.PROCESSLIST p 
  ON t.trx_mysql_thread_id = p.ID
WHERE TIMESTAMPDIFF(HOUR, t.trx_started, NOW()) >= 1;

重点关注 COMMAND = 'Sleep' 且 processlist_time > 3600 的行：这是典型的“连接挂着、事务没关”
如果 STATE 是 'Locked' 或 'Sending data'，说明事务还在干活，得先看 SQL 内容再决定是否干预
HikariCP、Druid 等连接池会让 ID 复用，PROCESSLIST 里看到的新查询，背后可能是老事务——所以必须靠 trx_mysql_thread_id 关联，不能只信 ID

别依赖 `SHOW ENGINE INNODB STATUS` 做日常监控

这个命令输出的信息全，但它是快照式、单次性的，而且结果被截断（默认只显示最近几条事务和锁信息），不适合自动化或定时巡检。

它不带时间戳字段，无法直接算出运行时长；你得手动比对 TRANSACTION 块里的 start time 字符串，易出错
输出内容格式不稳定，不同 MySQL 版本字段顺序、命名可能变化，写脚本解析风险高
权限要求更高：PROCESS 权限就够了，但 INNODB STATUS 在某些版本还需 SUPER 或 ENCRYPTION_KEY_ADMIN
真正该用它的场景是：刚发现一个阻塞，临时登录上去抓死锁详情或锁等待链，而不是轮询查长事务