在数据库性能调优与故障排查过程中，实时监控正在运行的事务是数据库管理员和开发人员的关键任务。然而，许多用户在MySQL 8.0及以上版本中尝试查询 INFORMATION_SCHEMA.TRX 表时会发现查询失败——因为该表并不存在。这通常是由于对性能模式（performance_schema）或旧版InnoDB监控器输出的记忆混淆所致。
实际上，要准确获取MySQL中活跃事务的实时状态，正确的途径是查询 information_schema.INNODB_TRX 表。该表由InnoDB存储引擎原生提供，无需任何额外配置即可直接使用，是查看当前事务最权威的数据源。
使用 information_schema.INNODB_TRX 查询当前运行事务
只要用户具备 PROCESS 权限，就可以直接查询此表来监控事务。一个基础而实用的查询语句如下：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX;
理解查询结果的各个字段，对于精准诊断问题至关重要：
trx_state揭示事务状态：此字段是判断事务所处阶段的核心。RUNNING表示事务正在活跃执行；LOCK WAIT表明事务正在等待获取锁资源；而ROLLING BACK或COMMITTING则代表事务正在结束过程中。trx_started标识事务时长：该时间戳是识别“长事务”或“僵尸事务”的关键依据。通常，运行时间超过数十秒的事务就需要引起警惕，进行深入分析。- 注意
trx_query的显示范围：此字段仅显示该事务中最后一条正在执行或已执行的SQL语句，并非事务完整的操作历史。若显示为空，可能意味着事务处于空闲状态或刚刚开始。 - 需要明确的是，此表仅记录采用InnoDB引擎的表所产生的事务。若应用中使用了MyISAM等非事务性引擎，相关操作不会在此表中体现。
为何查询 performance_schema 事务表时常为空？
许多用户也会尝试查询 performance_schema.events_transactions_current 来监控事务，但经常发现结果为空。根本原因在于，MySQL默认并未开启事务事件的监控采集功能。
若希望从性能模式中获取事务数据，需要手动启用对应的事件消费者（consumer）：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_transactions_current';
同时，还需确保 setup_instruments 表中，与事务（transaction）及InnoDB锁等待（wait/lock/innoDB/...）相关的监控项（instrument）也已处于启用状态。
这里有两点重要的实践建议：首先，开启这些监控功能会引入轻微的性能开销，在生产环境中建议根据实际排查需要临时开启，并在完成后及时关闭。其次，性能模式主要记录由 BEGIN 或 START TRANSACTION 显式开启的事务。在自动提交（autocommit）模式下执行的单条SQL，通常不会被记录到事务事件表中。
如何终止（Kill）长时间运行的事务？
当你通过 INNODB_TRX 表定位到一个可疑的长时间运行事务并决定终止它时，必须注意：无法直接通过事务ID（trx_id）进行操作。
正确的操作依据是连接线程ID，即 trx_mysql_thread_id 字段，它对应于 SHOW PROCESSLIST 命令结果中的 Id 列。终止命令如下：
KILL 12345;
在执行 KILL 命令前，务必进行谨慎确认：确保该事务状态为 RUNNING，且其开始时间（trx_started）确实异常，以避免误杀正常的短时业务事务。
如果事务状态是 LOCK WAIT，那么终止操作将杀掉等待锁的会话。但这可能并未解决根本问题，因为持有锁的会话可能仍在运行。此时，需要联合查询 INNODB_LOCK_WAITS 和 INNODB_LOCKS（在MySQL 8.0中相关表名可能有变化）来理清完整的锁依赖关系。
此外，对于MySQL 5.7或更早版本的用户，需注意一个历史细节：在极高并发场景下，INNODB_TRX 表中的 trx_mysql_thread_id 可能显示为0。遇到此情况，只能通过人工比对 PROCESSLIST 中的信息与事务开始时间等进行匹配。
总而言之，事务的状态、锁等待和持有信息分散在多个系统表中。要精准定位复杂的数据库阻塞或长事务问题，通常需要将 INNODB_TRX、INNODB_LOCK_WAITS 以及锁信息表进行联合查询与分析，才能获得全局视图。
