从库INNODB_TRX为空是正常现象，因SQL线程以autocommit=1回放事件，事务瞬时提交；应关注SHOW SLAVE STATUS、Replica_SQL_Running_State及GTID差值等复制状态指标。
MySQL 从库上查不到“正在执行的事务”——因为从库默认不开启事务上下文，INNODB_TRX 为空是正常现象，不是配置错了。
为什么 INFORMATION_SCHEMA.INNODB_TRX 在从库基本为空
从库（replica）的 SQL 线程默认以 autocommit = 1 方式回放 relay log 中的事件，每条 DML/DDL 都是独立短事务，提交后立即释放事务状态。因此：
-
INNODB_TRX只显示“尚未提交”的活跃事务，而从库 SQL 线程几乎不留驻事务（除非遇到大事务或复制延迟卡住） - 即使你手动在从库上
BEGIN一个事务，INNODB_TRX也能查到，但这和复制无关，属于你主动发起的会话事务 -
innotop默认连接的是本地实例，它读的仍是INNODB_TRX，所以从库上运行innotop的 “T” 模式（Transactions）通常无内容或仅显示瞬时快照
sys.innodb_lock_waits 和 performance_schema.data_locks 在从库是否可用
这两个视图依赖底层锁信息采集，但受制于从库的 SQL 线程行为：
-
sys.innodb_lock_waits是基于performance_schema.data_lock_waits的封装，在 MySQL 8.0+ 从库上能查，但绝大多数情况下返回空——因为 SQL 线程不长期持锁 -
performance_schema.data_locks可能显示少量锁（比如大事务回放中途、或你手动执行的 DML），但无法反映“复制中事务”的锁状态 - 若从库启用了
slave_parallel_type = LOGICAL_CLOCK且并发回放，锁可能分散在多个 worker 线程中，THREAD_ID和会话 ID 不再一一对应，关联难度陡增
真正该盯住的从库事务指标：SQL 线程状态 + relay log 进度
从库没有“用户级事务”概念，它的“事务性”体现在复制一致性上。排查卡顿或异常，应转向：
- 运行
SHOW SLAVE STATUS\G，重点关注：Seconds_Behind_Master（延迟秒数）、Slave_SQL_Running_State（如Waiting for dependent transaction to commit表示 MTS 依赖等待）、Retrieved_Gtid_Set与Executed_Gtid_Set差值 - 查 SQL 线程线程 ID：
SELECT THREAD_ID, PROCESSLIST_ID FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND NAME = 'thread/sql/slave_sql';，再用该PROCESSLIST_ID关联performance_schema.data_locks（仅当它确实在持锁时才有意义） - 监控
Replica_SQL_Running_State字段变化比查事务更直接——它本质就是从库“当前正在干的事”的状态描述
如果真要观察从库上的事务行为，唯一可靠方式是人工介入
想验证某条语句在从库上如何执行、是否加锁、耗时多久，只能主动触发：
- 先停复制：
STOP REPLICA; - 在从库上手动执行目标 SQL（例如
BEGIN; UPDATE ...; SELECT SLEEP(5);），此时INNODB_TRX、data_locks全部可查 - 注意：这会破坏复制一致性，仅限调试，操作完务必
START REPLICA;并核对Executed_Gtid_Set -
innotop此时可切到 “T” 模式看到你刚开的事务，但它的价值仅限于这个手工会话，不代表复制流本身
从库的事务“不可见”，不是监控盲区，而是设计使然。盯着 INNODB_TRX 找问题，在从库上大概率白忙——真正要盯的是 SQL 线程的状态机、GTID 差值、以及 SHOW ENGINE INNODB STATUS\G 中的 TRANSACTIONS 小节里那几行 “ACTIVE xxx sec” 的罕见长事务记录。
