MySQL Performance Schema 怎样找最慢摘要

线上看到“数据库变慢”时，直接盯着当前正在执行的 SQL 往往只能看到一个瞬间。更稳定的办法是查 performance_schema.events_statements_summary_by_digest：它会按 SCHEMA_NAME 和 DIGEST 聚合相似语句，再用总耗时、平均耗时、调用次数和样例 SQL 帮我们排优先级。

如果目标是找“最耗资源的一类语句”，先按 SUM_TIMER_WAIT 降序；如果目标是找“单次就很慢的语句”，再看 AVG_TIMER_WAIT 或高分位延迟。下面的查询只读 Performance Schema，不会修改业务表。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html

先记住三个判断：总耗时代表累计影响，平均耗时代表单次体验，调用次数决定一个看似不慢的摘要是否正在放大系统负担。

先确认语句摘要采集真的在工作

Performance Schema 的语句摘要依赖两层开关：语句类 instrument 负责记录语句事件，statements_digest consumer 负责维护摘要。MySQL 8.4 文档示例中，语句 instrument 和该 consumer 默认是开启的，但生产环境可能被启动参数或运行时配置改过，所以排查时先看状态。

-- 先确认语句 instrument 是否启用并计时
SELECT NAME, ENABLED, TIMED
FROM performance_schema.setup_instruments
WHERE NAME LIKE 'statement/%'
ORDER BY NAME
LIMIT 20;

-- 再确认摘要 consumer 是否启用
SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME = 'statements_digest';

这里不需要把所有采集项都重新打开。若发现摘要 consumer 是 NO，可以按变更流程评估后再启用；若只有某些语句 instrument 被关闭，摘要数据也可能出现偏科。排查结论要带上采集状态，否则“没有慢 SQL”可能只是“没有收集到”。

按总耗时和单次耗时分别找最慢摘要

摘要表里的计时单位是皮秒，展示时除以 1000000000000 才是秒。下面这条查询同时给出累计耗时、平均耗时和调用次数，先按累计耗时定位对整体影响最大的摘要。

-- 皮秒换算为秒，并排除没有库名或没有摘要文本的特殊行
SELECT
    SCHEMA_NAME,
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds,
    ROUND(AVG_TIMER_WAIT / 1000000000000, 6) AS avg_seconds,
    ROUND(MAX_TIMER_WAIT / 1000000000000, 3) AS max_seconds,
    SUM_ROWS_EXAMINED,
    SUM_ROWS_SENT,
    FIRST_SEEN,
    LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
  AND DIGEST IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

SUM_TIMER_WAIT 高，说明这类语句在观察窗口里消耗的总时间多，适合排查“系统整体被谁拖慢”。但它会把高频的短查询排到前面，所以还要看 AVG_TIMER_WAIT 和 COUNT_STAR：

-- 找单次延迟较高的摘要，同时保留调用次数避免误判冷门语句
SELECT
    SCHEMA_NAME,
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(AVG_TIMER_WAIT / 1000000000000, 6) AS avg_seconds,
    ROUND(QUANTILE_95 / 1000000000000, 6) AS p95_seconds,
    ROUND(QUANTILE_99 / 1000000000000, 6) AS p99_seconds,
    ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
  AND DIGEST IS NOT NULL
  AND COUNT_STAR > 0
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 20;

如果版本或环境没有可用的分位数列，可以只保留平均耗时和最大耗时。判断时不要只看 MAX_TIMER_WAIT：一次偶发抖动可能把最大值拉高，平均值、调用量和最近出现时间需要一起看。

用摘要文本和样例 SQL 缩小定位范围

DIGEST_TEXT 是把字面量替换成参数标记后的归一化文本，例如不同的用户编号可能被归到同一个摘要；QUERY_SAMPLE_TEXT 则提供曾经实际出现过的一条代表性 SQL。前者适合聚合同类问题，后者适合继续执行 EXPLAIN 或回到应用日志查调用方。

-- 只保留最近一段时间仍出现过的高累计耗时摘要
SELECT
    SCHEMA_NAME,
    DIGEST,
    DIGEST_TEXT,
    QUERY_SAMPLE_TEXT,
    QUERY_SAMPLE_SEEN,
    ROUND(QUERY_SAMPLE_TIMER_WAIT / 1000000000000, 3) AS sample_seconds,
    COUNT_STAR,
    ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
  AND DIGEST IS NOT NULL
  AND LAST_SEEN >= NOW() - INTERVAL 1 HOUR
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

拿到样例后，下一步是把它与应用接口、调用参数和执行计划对应起来，而不是把 DIGEST_TEXT 当成一条可以直接复制回放的完整业务请求。样例 SQL 可能被截断，也不能替代真实参数分布；它更适合作为定位入口。

遇到 NULL 摘要行时怎么处理

这张摘要表有固定容量。容量满后，无法匹配到已有摘要的语句会进入 DIGEST IS NULL 的 catch-all 行。因此看到这行并不等于某条 SQL 本身为空，而是说明一批未能单独保留的摘要被合并了。

-- 检查 catch-all 行占全部语句次数的比例
SELECT
    COUNT_STAR,
    ROUND(
        COUNT_STAR * 100.0 / NULLIF(SUM(COUNT_STAR) OVER (), 0),
        2
    ) AS count_percent,
    DIGEST_TEXT,
    QUERY_SAMPLE_TEXT
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NULL
   OR DIGEST IS NULL;

如果 catch-all 占比明显，复盘时记录观察窗口和工作负载，并评估在下次重启时增大 performance_schema_digests_size。不要为了“清零”直接在高峰期随意清空：TRUNCATE TABLE performance_schema.events_statements_summary_by_digest 会移除摘要行，清理后应重新开始一个明确的观察窗口。

推荐的运行手册顺序是：先保存当前高耗时摘要和时间范围，再决定是否清理；修复或调优后重新观察同一类指标；最后把高频、单次慢、偶发峰值和 catch-all 占比写进复盘。这样既能找到最慢摘要，也不会把一次清理后的空表误解为性能恢复。

常见问题

为什么总耗时最高的 SQL 不一定是单次最慢？因为总耗时是多次执行的累加，高频短查询可能超过低频长查询；单次延迟应看平均值和分位数。

为什么查询结果里的 SQL 和业务日志不完全一样？摘要会归一化字面量，样例 SQL 也可能被长度限制或采样策略影响，它是定位线索，不是完整调用记录。

查询结果为空怎么办？先看 performance_schema 是否可用，再检查 statement instruments、statements_digest consumer 和查询权限，最后确认观察窗口内确实有语句活动。

总结

查最慢摘要时，先确认采集，再用 SUM_TIMER_WAIT 找累计影响，用 AVG_TIMER_WAIT、分位延迟和 COUNT_STAR 补足单次体验与频率，最后借助 QUERY_SAMPLE_TEXT 追到执行计划和调用方。看到 DIGEST IS NULL 时，把它当成容量信号处理，而不是一条神秘慢 SQL。