INNODB_TRX.trx_query常为NULL，因InnoDB仅在SQL执行中短暂填充该字段，执行完成转入Sleep后即清空；trx_state='RUNNING'仅表示事务活跃，并非正在运行SQL；真正需关注的是trx_mysql_thread_id、HOST、USER、trx_started及锁信息等可查字段。
MySQL 无法直接查出未提交事务的完整 SQL 语句，尤其是事务空闲（Sleep）状态时 trx_query 为空、INFO 为 NULL —— 这是 InnoDB 的设计限制，不是配置或权限问题。
为什么 INNODB_TRX.trx_query 经常是 NULL
当事务执行完一条语句后进入等待状态（比如应用没发 COMMIT 或下一条 SQL），InnoDB 不会持续保留最后那条语句的文本。它只在语句「正在执行中」时短暂填充 trx_query；一旦执行完成、线程转为 Sleep，该字段就清空了。
-
trx_state = 'RUNNING'仅表示事务还活着，不表示有 SQL 正在跑 -
PROCESSLIST.COMMAND = 'Sleep'+TIME > 0是典型未提交但空闲的标志 - 即使关联
performance_schema.events_statements_current，也只能看到「最近一次执行的语句」，而非事务开头那条BEGIN后的全部操作
能查到什么？先确认你真正需要的信息
多数真实场景下，DBA 或开发真正关心的不是“原始 SQL 字符串”，而是：
- 哪个连接（
trx_mysql_thread_id）卡住了？ - 它连自哪里（
HOST）、谁（USER）、用了多久（TIME、trx_started）？ - 锁了哪些行（
trx_rows_locked）、改了多少行（trx_rows_modified）、隔离级别是什么（trx_isolation_level）？ - 是否正在阻塞别人（查
INNODB_LOCK_WAITS）？
这些都能通过组合查询拿到，例如：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT p.ID, p.USER, p.HOST, p.DB, p.TIME, t.trx_started, t.trx_isolation_level, t.trx_rows_locked, t.trx_rows_modified, t.trx_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' AND p.TIME > 10;
真要还原 SQL？只有三种有限路径
如果必须定位到事务最初执行的 DML（比如 UPDATE user SET status=1 WHERE id=123），只能依赖外部线索：
-
开启并回溯
general_log：需提前打开（SET GLOBAL general_log = 1），日志里按connection_id时间顺序可拼出事务全貌；但默认关闭，且 I/O 开销大，生产环境慎用 -
查
sys.session（MySQL 5.7+）：它基于performance_schema，字段last_statement和last_statement_latency可能保留最后一次执行语句，但同样不保证覆盖整个事务 - 应用端日志或 APM 工具：如 SkyWalking、Zipkin 或业务日志中记录了事务开启/SQL 执行/提交时间点，这是最可靠的方式 —— 数据库本身不存这个上下文
容易被忽略的关键点
很多人花几小时调查询语句，却忽略了两个硬性事实：
- InnoDB 事务上下文不持久化存储 SQL 文本，
trx_query是瞬态快照，不是历史记录 - 所谓「未提交事务的 SQL」在数据库视角里，其实是一组已执行完毕、等待用户决策（
COMMIT/ROLLBACK）的状态，而不是一个持续运行的命令流
与其强求还原，不如优先用 trx_started 和 TIME 定位长事务，再结合应用监控快速归因。
