登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

MySQL INFORMATION_SCHEMA.INNODB_TRX 怎么找出未提交事务:持续时间、线程映射与处理边界

来源:17golang原创

时间:2026-08-28 13:58:40 461浏览 收藏

线上写入突然变慢,第一反应不一定是索引或磁盘。一个迟迟没有提交的 InnoDB 事务,可能一直占着锁,也可能让 purge 长时间追不上。排查时可以先看 INFORMATION_SCHEMA.INNODB_TRX,再把事务线程映射到连接列表,最后才决定是否处理会话。

找未提交事务的关键不是只看“存在多久”,而是同时核对 TRX_STARTEDTRX_STATE、等待锁信息和对应连接;查询结果只负责提供证据,不能直接替代业务判断。

要点速览

  • INNODB_TRX 只反映当前正在 InnoDB 中执行的事务。
  • TRX_STARTED 用来计算持续时间,TRX_STATE 用来区分运行和锁等待。
  • TRX_MYSQL_THREAD_ID 可以关联 PROCESSLIST.ID,再补看用户、主机和当前语句。
  • 不要看到长事务就直接执行 KILL,先确认是否是批处理、备份或关键业务会话。

INNODB_TRX 能告诉你什么

MySQL 8.4 手册把 INNODB_TRX 定义为当前 InnoDB 事务的信息表。它能提供事务状态、开始时间、等待锁标识和关联的 MySQL 线程号,但它不是“所有连接的未提交清单”。只读且不加锁的事务可能没有 InnoDB 事务 ID,这也是只看连接空闲时间会误判的原因。

判断一条记录是否值得继续追,先看三个字段:TRX_STARTED 说明事务从什么时候开始,TRX_STATE 区分 RUNNINGLOCK WAIT 等状态,TRX_MYSQL_THREAD_ID 则负责把证据带回具体连接。

先用 INNODB_TRX 找出持续时间异常的事务

先做只读查询,把最需要的字段列出来。持续时间用当前时间减去 TRX_STARTED,不要把事务 ID 当成时间,也不要用连接的空闲秒数代替事务持续时间。

SELECT
    trx_id,
    trx_state,
    trx_started,
    TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_age_seconds,
    trx_wait_started,
    trx_requested_lock_id,
    trx_mysql_thread_id,
    trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

这里的筛选顺序很实用:先按 trx_age_seconds 找持续时间明显异常的记录,再看 trx_stateLOCK WAIT 表示它正在等锁,RUNNING 则只代表事务仍处于运行状态,并不自动说明它正在阻塞别人。

INNODB_TRX 通过 TRX_STARTED、TRX_STATE 和 TRX_MYSQL_THREAD_ID 形成事务排查证据链

把事务映射到连接

拿到 TRX_MYSQL_THREAD_ID 后,再去看连接的用户、主机和当前语句。最直接的关联是 INFORMATION_SCHEMA.PROCESSLIST.ID;如果正在使用 Performance Schema,也可以用线程表中的 PROCESSLIST_ID 做同一件事。

SELECT
    t.trx_id,
    t.trx_state,
    t.trx_started,
    t.trx_mysql_thread_id,
    p.user,
    p.host,
    p.db,
    p.command,
    p.time,
    p.state,
    p.info
FROM information_schema.innodb_trx AS t
LEFT JOIN information_schema.processlist AS p
  ON p.id = t.trx_mysql_thread_id
ORDER BY t.trx_started;

如果连接已经结束,左连接仍会保留事务侧证据,连接字段则为空;这时不要凭空补用户名或主机。需要更轻量地查看线程时,可以改查 Performance Schema 的 threads 表,但要确认账号具备对应查询权限。

TRX_MYSQL_THREAD_ID 关联 PROCESSLIST.ID 和 PROCESSLIST_ID,人工复核后才考虑 KILL

看到长事务后不要马上 KILL

长事务可能来自忘记提交的管理脚本,也可能是批量导入、报表查询或正在等待业务确认的流程。先记录事务开始时间、状态、关联用户和当前语句;如果是锁等待,再结合等待锁表确认谁在阻塞、谁在等待。

只有确认连接可以安全中断时,才把连接标识交给人工操作。KILL 的目标是连接线程,不是 trx_id;中断写事务还可能触发回滚,回滚本身也会持续一段时间。生产环境应先通知业务方,并保留处理前后的查询结果。

常见问题:三个容易误判的边界

只看到 RUNNING 就等于阻塞吗

不等于。RUNNING 只能说明事务仍在运行,是否阻塞要看锁等待关系、持有锁和其他会话的症状。

为什么连接列表里找不到对应行

事务和连接信息不是同一张表,查询瞬间也可能跨过连接结束或事务状态变化。用左连接保留事务证据,并在必要时重新查询核对。

只读事务为什么没有记录

只读且不加锁的事务可能不需要 InnoDB 事务 ID,因此不能用 INNODB_TRX 统计所有只读会话。

排查结果怎么收口

一轮可靠的排查至少留下三份信息:INNODB_TRX 的状态和开始时间、与连接列表的映射结果、以及采取或不采取处理动作的理由。这样既能定位真正的长事务,也能避免把正常批处理误杀成故障。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>