MySQL sys 语句延迟直方图的桶计数表示什么

MySQL sys 过程 ps_statement_avg_latency_histogram() 输出的“桶计数”，表示落在某个平均延迟区间内的规范化语句摘要数量。它不是请求总数，也不是某一条原始 SQL 的执行次数；过程先从 Performance Schema 的语句摘要统计中取平均延迟，再把这些平均值分配到延迟桶中。

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

读图时先看区间，再看区间右侧的数字。比如 (0 - 66ms) 88 可以理解为有 88 个被跟踪的规范化语句摘要，其平均延迟落在这个桶内；它不能直接推出某个摘要执行过 88 次。

这个直方图到底统计什么

CALL sys.ps_statement_avg_latency_histogram() 展示的是当前 MySQL 实例内，Performance Schema 已跟踪的规范化语句摘要平均延迟的高层分布。规范化会把具体参数值抽象掉，使结构相近的语句归入同一个 digest；因此图中的一个“语句”更接近一个摘要行，而不是一次客户端请求。

该过程适合快速回答“延迟主要集中在哪些区间”“是否存在少量明显偏慢的摘要”这类问题。它不负责告诉你慢的是哪条 SQL，也不替代按 digest 的明细查询。

桶区间和 COUNT_BUCKET 怎么读

Performance Schema 的语句直方图把延迟按桶保存。每个桶有 BUCKET_TIMER_LOW 和 BUCKET_TIMER_HIGH 两个边界，计数对应的区间是“包含下界、不包含上界”，也就是：

[BUCKET_TIMER_LOW, BUCKET_TIMER_HIGH)

因此，COUNT_BUCKET 的准确含义是：测得的语句延迟大于等于当前桶下界，并且小于当前桶上界的语句数量。第一个桶的下界从 0 开始；最后一个桶是兜底桶，用来接收超过前面区间的延迟。

sys 过程把边界格式化成毫秒并输出一个较高层的实例级图。例如：

CALL sys.ps_statement_avg_latency_histogram()\G
-- 调用 sys 过程，查看实例内摘要平均延迟的分布

(0 - 66ms)     88  | #############################
(66 - 133ms)   14  | ..............
(133 - 199ms)   4  | ....
(199 - 265ms)   5  | **
-- 每行的数字是当前延迟桶中的摘要数量，不是图形字符数量

这里第二行的 14 表示 14 个摘要的平均延迟位于 66ms（含）到 133ms（不含）之间。若某个平均延迟恰好等于 133ms，它会进入下一个桶，而不会同时计入两个桶。

右侧的点号、星号和井号是什么

输出顶部会给出图例，例如 . = 1 unit、* = 2 units、# = 3 units。这些字符只是把计数压缩成可读的横条：点号代表 1 个单位，星号代表 2 个单位，井号代表 3 个单位。真正的计数仍然是竖线左边的数字。

所以不能通过横条的字符个数反推精确数量。一个桶可能有 88 个摘要，显示为 29 个井号加一个字符；另一个桶有 5 个摘要，可能显示为两个星号和一个点号。图形便于比较形状，数字才适合做记录和阈值判断。

COUNT_BUCKET_AND_LOWER 与 BUCKET_QUANTILE 有什么区别

如果只看 COUNT_BUCKET，你只能知道当前一个区间里有多少摘要。要回答“延迟不超过这个桶上界的摘要占多少”，就要看累计字段：

例如某一桶的 COUNT_BUCKET 是 6，而从第一桶累加到该桶后的 COUNT_BUCKET_AND_LOWER 是 10，总计数是 17，那么这一桶本身只有 6 个摘要，但不超过当前上界的摘要一共有 10 个，BUCKET_QUANTILE 约为 0.5882。

这个比例是分桶统计提供的累计比例，不等同于严格精确的逐条延迟百分位。它能帮助你判断分布位置，但若需要针对某个 digest 做更细的 P95/P99 分析，应该继续查询对应的摘要和直方图表。

怎样从实例级直方图下钻到具体摘要

sys 过程的输出没有列出具体 digest。遇到某个高延迟桶占比异常时，可以先查看按 digest 的语句摘要，再用 digest 关联直方图表。下面的查询只保留有计数的桶，并按桶号排序：

SELECT
    h.SCHEMA_NAME,
    h.DIGEST,
    h.BUCKET_NUMBER,
    h.BUCKET_TIMER_LOW,
    h.BUCKET_TIMER_HIGH,
    h.COUNT_BUCKET,
    h.COUNT_BUCKET_AND_LOWER,
    h.BUCKET_QUANTILE
FROM performance_schema.events_statements_histogram_by_digest AS h
WHERE h.COUNT_BUCKET > 0
  -- 先按摘要和桶号排列，便于还原每个摘要的分布
ORDER BY h.SCHEMA_NAME, h.DIGEST, h.BUCKET_NUMBER;

如果要把 digest 对应到可读的规范化 SQL，可以再连接 events_statements_summary_by_digest，读取其中的 DIGEST_TEXT、COUNT_STAR、AVG_TIMER_WAIT 等字段：

SELECT
    s.SCHEMA_NAME,
    s.DIGEST,
    s.DIGEST_TEXT,
    s.COUNT_STAR,
    s.AVG_TIMER_WAIT,
    s.QUANTILE_95,
    s.QUANTILE_99
FROM performance_schema.events_statements_summary_by_digest AS s
WHERE s.DIGEST IS NOT NULL
  -- 先找平均延迟较高的摘要，再回到直方图看分布形状
ORDER BY s.AVG_TIMER_WAIT DESC
LIMIT 20;

这些查询的边界要记住：Performance Schema 的摘要表有容量上限，表满时无法为每个新 digest 建立独立行，未匹配的语句可能进入 DIGEST IS NULL 的汇总行。直方图本身也会受到采集开关和表截断的影响，因此它是观测窗口内的统计，不是永久历史。

读懂一张图时的紧凑判断法

1. 先确认过程统计的是摘要平均延迟，不把桶数字误当成单条 SQL 的执行次数。
2. 把每行看成左闭右开的延迟区间，当前数字只属于当前桶。
3. 用横条看相对形状，用数字看精确计数。
4. 需要累计结论时看 COUNT_BUCKET_AND_LOWER 和 BUCKET_QUANTILE。
5. 需要定位 SQL 时从实例级过程下钻到按 digest 的 Performance Schema 表。

一句话总结：sys 语句延迟直方图里的桶计数，是落在该平均延迟区间内的规范化语句摘要数量；它描述分布，不直接描述单条原始 SQL 的调用次数。累计计数和累计比例用于判断延迟上界覆盖了多少摘要，具体语句则要回到 digest 明细。

常见问题

桶计数能直接代表 SQL 执行次数吗？

不能。桶计数统计的是摘要平均延迟落入区间的摘要数；执行次数要看摘要表中的 COUNT_STAR 等字段。

为什么图形字符数量和桶计数对不上？

因为字符按图例代表不同单位，井号、星号和点号是缩放显示。应以竖线左侧数字为准。

怎样查看某一条摘要的 P95 或 P99？

先在 events_statements_summary_by_digest 找到摘要，再查看其 QUANTILE_95、QUANTILE_99 和按 digest 的直方图分桶数据。