MySQL sys 的语句平均延迟直方图怎样读取

排查 MySQL 延迟时，先看一张分布图往往比盯着某一条慢 SQL 更快找到方向。sys.ps_statement_avg_latency_histogram() 做的事情很具体：它读取 Performance Schema 已跟踪的归一化语句摘要，把每条语句的平均延迟放入区间，再用文本字符展示每个区间有多少条语句。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/sys-ps-statement-avg-latency-histogram.html

MySQL sys 直方图先回答了什么

执行过程不需要传入参数：

-- 读取当前实例中被 Performance Schema 跟踪的归一化语句平均延迟分布
CALL sys.ps_statement_avg_latency_histogram()\G;

输出的每一行代表一个平均延迟区间，例如从几十毫秒到下一段几十毫秒。行首的数字是落入该区间的语句数量，竖线后面的字符只是按比例绘制的文本条。它回答的是“哪些平均延迟范围聚集了多少条语句”，不回答“最近一分钟有多少请求超时”。

这里的“语句”是归一化后的 digest。不同参数值、但结构相同的 SQL，通常会汇总到同一个摘要中。因此同一个桶里的数量更适合用来判断语句形态的延迟分布，不应直接当作业务请求数。

先读懂三个摘要字段，再看区间

输出末尾的摘要是阅读入口，建议按下面的顺序核对：

例如某一行写成 (66 - 133ms) 14，重点是“14 个归一化语句的平均延迟落在这个区间”。这不是说每条语句都执行了 66 到 133 毫秒，也不是 14 次请求的合计时长。

点号、星号和井号属于图例单位。它们把数量压缩成可读的字符条，具体一个字符代表多少个单位，要以输出顶部的图例为准。比较两个实例时，先比较数字和桶宽，再比较字符视觉长度。

从高延迟桶继续定位，而不是直接改参数

直方图适合做第一轮分流。若高延迟区间有明显长尾，先记下区间边界和观察时间，再查询语句分析视图，查看 digest 文本、执行次数、总延迟与平均延迟之间是否一致：

-- 从语句分析视图中取出平均延迟较高的摘要，继续定位具体 SQL 形态
SELECT digest_text, count_star, avg_latency, max_latency
FROM sys.statement_analysis
ORDER BY avg_latency DESC
LIMIT 10; -- 先取少量样本，避免排查时被大量文本淹没

如果直方图的尾部很长，但 statement_analysis 中只有少数摘要偏高，优先检查这些摘要对应的索引、锁等待、临时表和数据量变化。如果所有桶都偏高，问题可能在实例资源、连接层或统一的执行计划变化，不能只盯着某一条 SQL。

对比前后结果时，务必保持相近的采集窗口，并记录 Performance Schema 是否被清空或重置。一个刚重置过的实例和一个运行了数天的实例，直方图的样本范围不同，直接比较字符条会得到错误结论。

这张图的边界与排查清单

• 它不是请求百分位数：平均延迟分桶无法替代应用侧的 P95/P99，尤其不能用来证明尾部请求体验。
• 它依赖采集范围：未被 Performance Schema 记录的语句不会出现在图中，低样本量时结论要保守。
• 它不提供根因：高平均延迟只说明需要继续查 digest、锁、IO、计划或数据分布。
• 它适合先分流：先确定延迟集中在哪些区间，再选择具体语句做 EXPLAIN、锁等待和资源指标分析。

相关问题

MySQL sys 直方图能直接看出最慢的一次执行吗？

不能。它按归一化语句的平均延迟分桶，不能代替单次执行明细或应用侧的尾延迟指标。

为什么字符条很长，但数字并不大？

字符条使用图例规定的压缩单位，视觉长度不是毫秒数。应以每行的语句数量、图例和 Bucket Size 为准。

如何把直方图结果和慢 SQL 联系起来？

先记录区间与时间窗口，再到 sys.statement_analysis 或对应 digest 摘要中按平均延迟排序，最后结合索引、锁等待和执行计划确认根因。