查 innodb_trx 是定位长事务的唯一可靠方式，因其能准确反映事务开启时间及状态，而 show processlist 的 time 字段仅统计当前语句执行时长；需重点关注 trx_state = 'running' 且 trx_query is null 的空闲未提交事务。
查 INNODB_TRX 是定位长事务的唯一可靠方式
别信 SHOW PROCESSLIST 里的 Time 字段——它只统计当前语句执行时长，不是事务开启时间。真正钉住 undo log 的，是那些 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务：它们早已空闲，却没提交，undo 全被锁死。
执行这个查询能快速揪出问题：
SELECT trx_mysql_thread_id AS thread_id,
trx_started,
TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec,
trx_state,
trx_rows_modified,
SUBSTRING(trx_query, 1, 100) AS trx_query_truncated
FROM information_schema.INNODB_TRX
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600;
- 阈值设 600 秒（10 分钟）较稳妥：太短会误杀重试逻辑或慢但合法的批处理；太长则 undo 已开始膨胀，
History list length可能飙到几十万 -
trx_rows_modified > 0且duration_sec > 60就要盯紧——这类事务最可能正在回滚或已卡死 -
trx_mysql_thread_id和PROCESSLIST.ID一一对应，可立刻 JOINperformance_schema.threads查客户端 IP、用户、数据库名
KILL 前必须看 trx_state 和 purge 状态
直接 KILL 12345 看似快，但若该事务已修改上万行，InnoDB 正在回滚，KILL 只会让回滚更慢、更占 IO，甚至拖垮 purge 线程。必须分情况处理：
-
trx_state = 'RUNNING'且trx_query IS NULL：事务空闲中，极大概率是应用层没调COMMIT或ROLLBACK，可安全KILL -
trx_state = 'LOCK WAIT'：它正卡在等锁，得先查INNODB_LOCK_WAITS找出 blocking 事务，优先干掉上游 -
trx_state = 'ROLLING BACK'：别动，等它自己结束；此时innodb_fast_shutdown = 0重启也无效，只会延长恢复时间
如果 SHOW ENGINE INNODB STATUS 里 “History list length” 超过 10000，说明 purge 已严重滞后，批量 KILL 会雪上加霜，建议加 SLEEP(0.2) 间隔执行。
监控必须固化成自动告警，不能靠人工巡检
MySQL 自身不提供“事务运行超 X 分钟”告警，得靠定时查询 INNODB_TRX 主动捞数据。日常巡检容易漏，必须变成自动触发动作：
- 运行超 300 秒（5 分钟）的事务数 > 3：发企业微信/钉钉告警，附带
trx_id、thread_id、duration_sec、trx_query截断前 100 字符 -
History list length> 50000：立刻升级为 P1 级别，需人工介入查INNODB_TRX+INNODB_SESSIONS关联分析 - 可用 Prometheus 抓取
mysql_info_schema_innodb_trx_duration_seconds和mysql_engine_innodb_status_history_list_length这两个指标（截至 2026 年 4 月 21 日）
真正治本：从应用侧切断长事务源头
所有数据库层的调参都是兜底手段。undo 膨胀的根因永远在应用：
- 禁止在事务里做 HTTP 请求、文件读写、
SLEEP等耗时操作 - 批量更新必须分页，单次事务控制在 1000 行以内（配合
COMMIT） - ORM 框架（如 MyBatis、Django）要显式配置
autocommit=true，避免隐式事务跨请求 - 客户端可设
SET MAX_EXECUTION_TIME = 300000（5 分钟），防意外长事务占用资源
最容易被忽略的是：事务提交后，连接未必归还给连接池——有些框架或中间件在异常路径下漏关连接，导致看似“已提交”的事务，其会话仍持有一个空闲但未释放的事务上下文。这点在压测或异常流量突增时特别致命。
