如何在MySQL中识别并修复由于连接池导致的未提交事务？-mysql教程-PHP中文网

查未提交事务不能只看innodb_trx，必须关联processlist验证连接状态：通过trx_mysql_thread_id与p.id连接，过滤command≠'sleep'且trx_state='running'的活跃线程，结合user、host、conn_time定位连接池泄漏。

如何在mysql中识别并修复由于连接池导致的未提交事务？

查未提交事务不能只看 `INNODB_TRX`，得关联连接池线程状态

单纯执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 只能看到事务本身，但无法判断它是否来自连接池中“被复用却没清理干净”的连接。真实场景中，很多未提交事务是应用从连接池取到一个旧连接（上个请求没正确结束事务），直接执行新 SQL 导致的。必须把事务线程 ID 和连接池当前活跃连接对上。

推荐组合查询：

SELECT 
  t.trx_id, 
  t.trx_mysql_thread_id, 
  t.trx_started, 
  t.trx_state, 
  t.trx_query,
  p.ID AS processlist_id,
  p.USER,
  p.HOST,
  p.DB,
  p.COMMAND,
  p.TIME AS conn_time,
  p.STATE
FROM INFORMATION_SCHEMA.INNODB_TRX t
JOIN INFORMATION_SCHEMA.PROCESSLIST p 
  ON t.trx_mysql_thread_id = p.ID
WHERE t.trx_state = 'RUNNING' 
  AND p.COMMAND != 'Sleep'
ORDER BY t.trx_started;

trx_state = 'RUNNING' 排除已提交或回滚但尚未释放的伪活跃事务
过滤掉 COMMAND = 'Sleep' 的线程，它们大概率是空闲连接，不持有有效事务
重点看 USER 和 HOST 是否匹配你应用的连接池配置（比如统一用 app_pool 用户）
conn_time 显著大于业务正常耗时（如 > 30 秒），基本可判定为泄漏

连接池配置不当会掩盖事务泄漏，`leak-detection-threshold` 必须开

HikariCP、Druid 等主流连接池默认不检测连接泄漏，导致事务卡住数小时都无人发现。MySQL 层面看到的是“正常运行中”的事务，而应用层以为连接已归还。

MySQL

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

下载

HikariCP 必须显式设置：leak-detection-threshold=60000（单位毫秒），超 60 秒未归还就打印 WARN 日志并带上堆栈
Druid 对应参数是：removeAbandonedOnBorrow=true + removeAbandonedTimeoutMillis=60000
别依赖 maxLifetime 或 idleTimeout 自动回收——它们只管连接对象生命周期，不管事务是否提交
开启后日志里出现类似 Connection leak detection triggered 就要立刻查对应代码段：是不是 try 块里没进 finally、或者异常分支漏了 connection.rollback()

修复时不能直接 `KILL` 线程，先确认是否还在被应用使用

盲目执行 KILL 12345 可能导致应用端报 Communications link failure，甚至引发二次异常（比如重试逻辑叠加）。尤其在微服务调用链中，一个 KILL 可能让上游误判为超时重试，放大问题。

先用 SHOW PROCESSLIST 看该线程的 STATE：如果是 Locked 或 Sending data，说明还在干活，等它自然结束更安全
如果 STATE 是 Query 且 INFO 字段为空（即没在执行 SQL），但 TIME 很大，基本可确定卡在事务里，此时再 KILL
生产环境建议加条件：只 KILL 持续时间 > 300 秒、且 USER 匹配应用账号的线程，避免误杀监控或备份连接
执行 KILL 后，立刻检查应用日志——如果大量出现 Transaction is not active 或 Connection reset，说明有代码依赖该连接做后续操作，得回溯修复

根本解法不是调参，而是让每个连接在归还前强制清理

靠 DBA 定期巡检 INNODB_TRX 是被动防御。真正可靠的方案，是在连接归还连接池前，由连接池主动执行清理语句。

HikariCP 支持 connection-init-sql=SET autocommit = 1; COMMIT;（注意：MySQL 8.0.3+ 才支持多语句）
更通用的做法是配置 connection-test-query=SELECT 1 + test-while-idle=true，并在测试 SQL 前插入清理逻辑（需自定义 DataSource 包装器）
最稳妥的仍是代码层规范：所有手动事务必须用 try-finally 包裹，finally 中明确调用 connection.rollback() 或 commit()，而不是依赖连接关闭自动回滚
容易被忽略的一点：AUTOCOMMIT=1 的连接执行 START TRANSACTION 后，仍需显式 COMMIT；连接池不会帮你补这个动作