查 innodb_trx 本身不会拖慢数据库，因其是内存只读快照，无锁无日志无磁盘扫描；但高并发下遍历活跃事务、字段拷贝及权限校验会引发隐性开销，尤其 trx_rows_modified 或 trx_lock_structs 极大时成本线性上升。
查 INNODB_TRX 本身会拖慢数据库吗？
不会——INFORMATION_SCHEMA.INNODB_TRX 是 InnoDB 内存结构的只读快照视图，查询它不触发锁、不写日志、不扫描磁盘，开销极低。但“低”不等于“零”，尤其在高并发事务场景下，它的性能损耗是隐性的：每次查询都要遍历所有活跃事务的内存结构，并做字段拷贝和权限校验。当 trx_rows_modified 或 trx_lock_structs 值极大（比如一个事务改了 50 万行、持了上万个锁），视图构造成本会线性上升。
为什么频繁查 INNODB_TRX 可能引发 CPU 尖刺？
根本原因不是 SQL 本身慢，而是 SELECT * FROM information_schema.INNODB_TRX 在高并发下会争抢 trx_sys->mutex（InnoDB 事务系统全局互斥锁）。MySQL 8.0 对该锁的优化有限，若每秒执行几十次这类查询（比如监控脚本轮询间隔设为 1s 且未加限流），就会出现明显锁竞争，表现为 show engine innodb status 中 SEMAPHORES 区域的 os_waits 暴涨，CPU 使用率同步抬升。
- 避免全表扫：永远不要
SELECT *，只取真正需要的字段，例如trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_rows_modified - 加 WHERE 过滤：如果只关心运行超 60 秒的事务，用
WHERE trx_started ，能跳过大部分短事务遍历 - 控制频率：生产环境轮询间隔建议 ≥ 10s；若需实时感知，优先用
performance_schema.events_transactions_current（开启后）替代，它底层更轻量
trx_query 字段为空或截断时，是否说明查询没走索引？
不是。这个字段值为空，只代表该事务至今没执行过任何 SQL 语句（比如刚 BEGIN 就挂起），和索引无关；而被截断（默认显示前 1024 字节）是视图定义限制，跟执行计划完全无关。真正影响索引选择的是优化器决策，要看 EXPLAIN 结果。误把 trx_query 当作慢查询线索，常导致排查方向错误。
-
trx_query为空 ≠ 事务空闲：可能是事务开了但还没发 DML，也可能是应用层连接池复用后忘记提交 -
trx_rows_modified > 0且trx_query IS NULL：高度可疑，大概率是长事务卡在应用层未提交，需结合trx_started和应用日志确认 - 别依赖它定位慢 SQL：要用
performance_schema.events_statements_history或慢日志，INNODB_TRX的trx_query只是“最后一句”，不是“最重一句”
INNODB_TRX 和 performance_schema.data_locks 联查时容易卡住？
会。这两张表底层数据源不同：INNODB_TRX 来自 InnoDB 内存事务链表，performance_schema.data_locks 来自 P_S 的锁事件缓冲区。当两者 JOIN 查询（如 ON trx_id = ENGINE_TRANSACTION_ID）时，MySQL 会强制做全量匹配，且无法利用索引加速——因为 ENGINE_TRANSACTION_ID 在 data_locks 中是字符串类型，而 trx_id 是 bigint，隐式转换导致全表扫描。
- 改用关联字段：用
trx_mysql_thread_id关联performance_schema.threads.THREAD_ID，再连data_locks，效率高得多 - 分步查比 JOIN 更稳：先查出问题
trx_mysql_thread_id，再单独查SELECT * FROM performance_schema.data_locks WHERE THREAD_ID = ? - 注意版本差异：MySQL 8.0.30+ 修复了部分 JOIN 性能问题，但低于此版本务必避开跨引擎 JOIN
真正耗资源的从来不是单次查询，而是高频、无过滤、盲目 JOIN 的使用方式。排查时盯着 trx_state 和 trx_started 就够用，其他字段按需取，别把它当万能日志表用。
