事务事件统计必须先开启对应instrument和consumer，否则events_transactions_summary_by_digest等表为空；需同时启用transaction相关instrument及eventstransactions* consumer，且二者须配对生效。
直接结论：事务事件统计必须先开启对应 instrument 和 consumer，否则 events_transactions_summary_by_digest 等表始终为空，查不到任何数据。
为什么查不到事务统计？——setup_instruments 和 setup_consumers 必须配对开启
MySQL 默认只开启部分 instrument（如语句类），但 transaction 相关的采集是关闭的。即使你启用了 performance_schema=ON，也不代表事务事件自动收集。
-
setup_instruments控制“采集什么”：需显式启用transaction和transaction/abstract（5.7+）或transaction/%（8.0+） -
setup_consumers控制“存到哪”：必须开启events_transactions_current、events_transactions_history、events_transactions_history_long才能写入汇总表 - 常见错误：只改了
my.cnf中的performance-schema-instrument='transaction=ON'，却没开对应的 consumer，结果events_transactions_summary_by_digest仍是空的
events_transactions_summary_by_digest 是核心分析入口
这张表按 SQL 摘要聚合事务级指标，比单条事务记录更实用。它不依赖线程或用户维度，适合快速定位高开销事务模式。
- 关键字段：
DIGEST_TEXT（标准化后的事务内 SQL）、COUNT_STAR（执行次数）、SUM_TIMER_WAIT（总耗时纳秒）、AVG_TIMER_WAIT（平均耗时） - 注意：
DIGEST_TEXT可能是BEGIN或空，因为事务本身无固定 SQL 形式；真正有用的是事务内第一条SELECT/UPDATE/INSERT的 digest —— 这取决于你是否开启了statement类 instrument 并关联了 transaction ID - 示例查询（找最慢事务摘要）：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000 AS total_sec, AVG_TIMER_WAIT/1000000000 AS avg_sec FROM performance_schema.events_transactions_summary_by_digest WHERE SUM_TIMER_WAIT > 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
事务统计和语句统计的关系不能直接 join
很多人试图用 THREAD_ID 或 EVENT_ID 关联 events_transactions_current 和 events_statements_history，但实际不可靠：
- 事务事件和语句事件在
performance_schema中是独立流水线，没有外键约束 - 同一事务内的多条语句可能被不同 consumer 记录，且历史表保留数量不同（
history默认每线程 10 条，history_long默认 10000 条） - 正确做法：先用
events_transactions_history_long找出目标事务的TRANSACTION_ID，再结合events_statements_history_long中的NESTING_EVENT_ID或EVENT_ID匹配（仅当NESTING_EVENT_TYPE = 'TRANSACTION'时成立） - 性能代价高：两表都默认不索引，大库上全表扫描极慢，建议先用
WHERE TIMER_WAIT > xxx缩小范围
容易被忽略的细节：事务聚合规则和隔离级别影响
events_transactions_summary_by_digest 的聚合逻辑不是简单按 SQL 文本分组，而是受事务边界和 isolation level 影响：
- 显式
BEGIN/START TRANSACTION启动的事务，其内所有语句归入同一事务 digest；但 autocommit=1 时，每条 DML 自成事务，digest 就是那条语句本身 - READ COMMITTED 和 REPEATABLE READ 下，同一条 SQL 在不同事务中可能产生不同 digest（例如因隐式锁升级或 MVCC 版本差异），导致统计分散
-
TRUNCATE TABLE对事务统计表无效 —— 这些表是只读视图，不能清空，只能重启 MySQL 或重置setup_*表来“刷新”统计
