information_schema.innodb_trx返回空，是因为该表仅显示当前活跃的innodb事务（已开始、未提交/回滚），若无长事务、无锁等待、无未提交dml，或权限不足（需process权限）、事务已结束、操作非innodb表等，均导致为空。
查 INFORMATION_SCHEMA.INNODB_TRX 为什么返回空？
直接执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 返回空，大概率不是表坏了，而是当前真没活跃事务。这个表是内存快照，只显示正在运行、未提交、且涉及 InnoDB 表的事务——纯 SELECT（自动提交）、已 COMMIT/ROLLBACK 的事务、MyISAM 表操作，都不会出现。
实操建议：
- 先用
SHOW ENGINE INNODB STATUS\G看输出里有没有TRANSACTIONS小节，这是交叉验证是否有真实活跃事务的黄金标准 - 确认账号有
PROCESS权限（SELECT权限不够） - 手动触发一个不提交的事务测试：
BEGIN; UPDATE t SET x=1 WHERE id=1;，再查INNODB_TRX就能看见数据了
trx_duration_sec 是判断长事务最直接的指标
别只看 trx_state = 'RUNNING'，它只表示“没卡在等锁”，不代表健康。真正危险的是运行时间过长的事务，比如超过 60 秒还没结束。
推荐用这个查询快速排序定位：
SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_duration_sec, trx_mysql_thread_id, trx_query, trx_rows_modified, trx_rows_locked FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_duration_sec DESC LIMIT 10;
注意点：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
trx_duration_sec超过业务预期（比如支付流程本该 2 秒内完成，却跑了 300 秒），就要立刻盯住对应trx_mysql_thread_id，去PROCESSLIST查线程状态 - 如果
trx_query是NULL，说明事务处于空闲状态（比如应用拿了连接但没发 SQL），常见于连接池未正确 commit/rollback 后归还连接 -
trx_rows_modified > 0且持续很久，意味着大量 undo log 没刷盘，crash 后恢复慢，回滚代价极高
trx_state = 'RUNNING' 且 COMMAND = 'Sleep' 最危险
很多人以为只有 LOCK WAIT 才要管，其实更隐蔽的风险来自表面“休眠”实则“占着茅坑”的事务：它们 trx_state = 'RUNNING'，但在 PROCESSLIST 里显示 Command = 'Sleep'，Time 值很大。
这类事务通常源于：
- 应用代码忘记在 try-catch 后写
COMMIT或ROLLBACK - 连接池配置了
autoCommit=false，但没做事务边界管理 - 网络中断或客户端崩溃，连接没断但事务卡住
它们不会报错，但会一直持有锁、阻塞其他 DML、拖慢 MVCC 清理——排查时务必把 INNODB_TRX 和 PROCESSLIST 关联查：
SELECT t.trx_id, t.trx_started, t.trx_state, p.ID AS thread_id, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.STATE, p.INFO FROM INFORMATION_SCHEMA.INNODB_TRX t JOIN INFORMATION_SCHEMA.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID WHERE p.COMMAND = 'Sleep' AND TIMESTAMPDIFF(SECOND, t.trx_started, NOW()) > 60;
结合 trx_rows_locked 和 trx_rows_modified 判断事务影响面
光看时间不够，得知道它锁了多少、改了多少。这两个字段才是评估“长事务危害等级”的核心：
-
trx_rows_locked过大（比如 > 10000），说明它锁住大量记录，极易引发连锁阻塞；尤其在 RR 隔离级别下，可能让其他事务反复重试或超时 -
trx_rows_modified高（比如 > 5000），代表大量未提交变更，占用 buffer pool 和 undo space；若突然 kill，回滚过程可能持续数分钟，期间整个实例 IO 压力飙升 - 二者同时高，基本可判定为“事故级事务”，应优先 kill（
KILL <code>thread_id）并推动应用修复逻辑
容易被忽略的一点：trx_rows_locked 包含标记为已删除但尚未 purge 的行，所以数值可能比实际业务感知的“活跃锁定行数”略高——不能只看绝对值，要结合业务语义判断是否合理。
