MySQL Performance Schema events_statements 如何找平均耗时

排查 MySQL 慢 SQL 时，很多人会直接查 events_statements_current，但这张表回答的是“某个线程此刻或最近发生了什么”，并不适合直接求某类 SQL 的平均耗时。要看规范化 SQL 的平均值，应查询 performance_schema.events_statements_summary_by_digest，读取 AVG_TIMER_WAIT，再把皮秒换算成毫秒。

一、先确认平均耗时到底从哪张表读

Performance Schema 会把形如 SELECT ... WHERE id = 1、SELECT ... WHERE id = 2 的语句规范化，再按库名和 digest 聚合。聚合表里保留的是一类 SQL 的次数、总耗时、最小值、平均值和最大值，因此标题里所说的“平均耗时”对应 AVG_TIMER_WAIT。

events_statements_current、events_statements_history 和 events_statements_history_long 更适合查看单次事件；不要把其中几行手工平均后当作服务器长期平均值。下面这张图只表达数据关系，是操作示意图，不是本机截图。

二、先检查采集开关，再查摘要行

如果摘要表没有新数据，先看 consumer 和语句 instrument。MySQL 官方快速入门示例通过 setup_instruments 的 ENABLED、TIMED 控制采集和计时，通过 setup_consumers 控制事件去向。生产环境不要无差别开启所有项目，先按实例负载和权限做评估。

-- 先确认 digest 聚合和语句计时是否开启
SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME = 'statements_digest';

-- 查看语句 instrument 的开关，重点关注 TIMED
SELECT NAME, ENABLED, TIMED
FROM performance_schema.setup_instruments
WHERE NAME LIKE 'statement/sql/%'
ORDER BY NAME
LIMIT 20;

-- 仅在确认需要时开启语句计时与 digest consumer
UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'statement/sql/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME = 'statements_digest';

若当前账号不能修改这些表，只能让 DBA 调整配置；查询权限不足与“没有语句发生”在结果上都可能表现为空，需要分别确认。

三、换算单位后再判断平均耗时

下面的查询按平均计时从高到低列出 digest。Performance Schema 的 timer 值是近似皮秒，所以除以 1000000000 得到毫秒；如果想看秒，则除以 1000000000000。

-- 按规范化 SQL 找平均耗时，并保留判断所需的上下文
SELECT
    SCHEMA_NAME,
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(AVG_TIMER_WAIT / 1000000000, 3) AS avg_ms,
    ROUND(SUM_ROWS_EXAMINED / NULLIF(COUNT_STAR, 0), 1) AS avg_rows_examined,
    SUM_NO_INDEX_USED,
    FIRST_SEEN,
    LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT IS NOT NULL
  AND SCHEMA_NAME = '业务库名'
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 20;

这里的 业务库名 需要替换成实际 schema；不想限定库时可以删掉这一行。DIGEST_TEXT 是规范化后的示例文本，COUNT_STAR 表示聚合次数。平均值高但只执行过一两次，和平均值略高却执行几十万次，处理优先级并不相同。

另外，AVG_TIMER_WAIT 不是百分位数。它适合发现整体变慢的 SQL 类型；若要判断长尾，还要结合直方图摘要或单次事件，不能用平均数替代 P95/P99。

四、用短窗口核对聚合结果

摘要表会持续累加。若你要回答“刚刚这十分钟的平均耗时”，可在明确允许丢弃当前统计的情况下清空 digest 摘要，等待固定窗口后再查询；这会删除该摘要表的行，也会连带清空对应的 digest 直方图，生产环境应先取得变更许可。

-- 只在已确认统计窗口可以重置时执行
TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;

-- 窗口结束后重新查询最近聚合结果
SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR,
       ROUND(AVG_TIMER_WAIT / 1000000000, 3) AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT IS NOT NULL
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 10;

核对时至少看三点：LAST_SEEN 是否落在观察窗口内，COUNT_STAR 是否随压测或业务请求增长，以及 events_statements_history_long 中是否能找到相同 SQL 类型的单次事件。三者都对得上，平均值才有可解释性；摘要表满时还要留意 SCHEMA_NAME、DIGEST 为 NULL 的 catch-all 行，它不能代表一个具体 SQL。

相关问题

AVG_TIMER_WAIT 为什么看起来特别大？

它以皮秒保存，直接展示原值很容易误读。先除以 1000000000 转成毫秒，再比较不同 SQL。

能不能从 events_statements_current 直接求平均？

可以对当前取到的事件做临时统计，但它是瞬时或有限历史窗口，不等于 digest 摘要的持续聚合平均值。

平均耗时高就一定是索引问题吗？

不一定。还要结合执行次数、锁时间、扫描行数和执行计划判断；平均值只能告诉你“这类语句整体花费较多”。