postgresql用户用percentile_cont(0.99) within group (order by latency_ms)计算p99，需配合time_bucket()或date_trunc()分组；mysql需percentile_cont()加over(order by)；prometheus须预计算histogram_quantile；告警需reduce取max/mean并统一时间窗口。
如何用 SQL 在 grafana 中计算 P99 延迟
Grafana 本身不直接支持百分位计算，得靠数据源（如 PostgreSQL、MySQL、Prometheus + pg_exporter）的聚合能力。PostgreSQL 用户最稳：用 percentile_cont()；MySQL 8.0+ 可用 PERCENTILE_CONT() 窗口函数，但注意它必须配合 OVER() 和排序，不能当普通聚合用。
常见错误是写成 select PERCENTILE_CONT(0.99) FROM logs —— 这会报错，因为没指定排序依据。正确写法必须带 ORDER BY latency_ms：
SELECT time_bucket('5m', time) AS t, percentile_cont(0.99) WITHIN GROUP (ORDER BY latency_ms) AS p99_latency FROM http_requests WHERE time > now() - interval '1h' GROUP BY t ORDER BY t注意：time_bucket() 是 TimescaleDB 扩展函数，原生 PostgreSQL 需用 date_trunc('minute', time) 替代；如果用 Prometheus，得提前在 exporter 或 recording rule 里算好 histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))，否则 Grafana 查不了原生分位数。
Grafana 告警规则里怎么引用 P99 查询结果
告警阈值不能写死数字，得和 P99 曲线联动——本质是让告警条件基于同一查询的动态输出。关键点：告警规则必须用「Reduce」操作把时间序列压成单个标量，再和阈值比。
常见坑：last() 不可靠，P99 是统计值，可能因窗口内数据稀疏而跳变；推荐用 mean() 或 max()（看业务容忍度）：
- 在 Grafana 告警规则编辑页，Query 选中你的 P99 查询（比如 alias:
p99_latency） - 点击「Reduce」→ 选
Max（取最近 5 个点的最大 P99，防毛刺）或Mean（更平滑） - Condition 设为
WHEN last() OF query A IS ABOVE 1200，这里1200单位是毫秒，对应 1.2 秒阈值 - 别漏掉「No Data / NULL / Error Handling」设为 Keep Last，否则查不到数据时告警静默
P99 延迟曲线和告警不同步？检查时间范围对齐
图表显示的 P99 是过去 1 小时每 5 分钟一个点，但告警默认只看最近 10 分钟数据——两者窗口不一致，就会出现“图上已飙高，告警却没触发”。
必须手动统一：
- 图表查询里的
WHERE time > now() - interval '1h'要和告警规则的「Evaluate every」+「for」时间匹配 - 例如告警设为「每 2 分钟评估一次，持续 5 分钟触发」，那查询的 time range 至少得覆盖最近 7 分钟，否则 Reduce 拿不到足够点
- TimescaleDB 用户注意：
time_bucket()的区间左闭右开，time_bucket('5m', '2024-06-01 12:00:00')实际覆盖[12:00:00, 12:05:00)，别让告警窗口卡在桶边界上
为什么 P99 告警老是误报或漏报
根本原因常不在 SQL 或 Grafana 配置，而在数据质量本身：延迟字段为空、负数、单位混用（秒 vs 毫秒）、采样率过低。
实操排查顺序：
- 先查原始数据分布：
SELECT count(*), min(latency_ms), max(latency_ms), avg(latency_ms) FROM http_requests WHERE time > now() - interval '5m'—— 如果min是负数或max超过 60 秒，说明埋点有 bug - 确认单位：Prometheus 的
http_request_duration_seconds是秒，但 Grafana 图表 Y 轴标成 ms 就会误导；SQL 里统一转成毫秒：latency_ms * 1000 - 采样影响：如果只采集了 1% 请求，P99 统计就不可信；PostgreSQL 可加
TABLESAMPLE SYSTEM(10)测试，但生产环境务必全量 or 稳定采样策略
最易被忽略的是时间精度：PostgreSQL 的 timestamp without time zone 默认到微秒，但 Grafana 查询可能截断到秒，导致同一批请求被分到不同 time_bucket，P99 波动放大。统一用 timestamptz 并显式 cast 到毫秒级精度。