查询延迟高源于Prometheus执行PromQL时扫描过多时间序列、加载大量chunk及冗余计算，需从查询写法、数据结构、存储配置三方面协同优化。
查询延迟高，本质是 Prometheus 在执行 PromQL 时需要扫描过多时间序列、加载大量 chunk、做冗余计算。优化不是靠升级 CPU 或加内存，而是从查询写法、数据结构、存储配置三方面协同压降开销。
精简查询范围：先过滤，再聚合
Prometheus 查询性能高度依赖标签匹配效率。倒排索引对 = 和 != 匹配做了深度优化，但对 =~ 或空匹配器（如 {job=~".*"}）会触发全量扫描。
- 始终用精确匹配限定关键维度：例如
http_requests_total{job="api", status="500", cluster="prod"} - 避免在高基数标签（如
pod、instance）上使用正则；若必须区分，优先通过预定义标签（如service或tier）替代 - 时间范围设合理：大屏默认用
now()-6h，而非now()-30d；长期分析需明确业务周期，避免无意义拉长窗口
降低计算负载：用 recording rules 预聚合
实时计算（如嵌套 rate() + sum by()）每次查询都重跑，开销随时间序列数线性上升。把高频、固定逻辑的计算提前固化为新指标，查询时直接读取聚合结果。
- 例如将
sum by (service) (rate(http_requests_total[5m]))写成 recording rule，生成service:requests:rate5m - 对延迟类指标，用直方图 +
histogram_quantile(0.99, ...)替代手动分桶统计，减少多步聚合 - 避免跨长窗口的
rate(...[2h])—— 默认--query.lookback-delta=5m会导致重复采样，建议调至30s并搭配[5m]窗口
匹配存储结构：调优 TSDB 块参数与查询语义
Prometheus 按 block 切分数据，默认 2 小时一个 block。查询跨多个 block 时需加载多个 index 和 chunk，内存与 I/O 开销陡增。
- 缩短 block 时长：设
--storage.tsdb.max-block-duration=1h或2h，加快 compact，让查询聚焦更小数据集 - 禁用低效函数组合：如
count_over_time(http_requests_total[1h])会加载整小时所有样本；改用rate(http_requests_total[5m]) * 300更轻量 - 确认是否启用
exemplars：若未用于 trace 关联，建议关闭（--enable-feature=exemplars不启用），减少 chunk 元数据膨胀
规避常见陷阱：标签与函数误用
很多延迟问题源于“看似合理”的写法，实际放大了计算规模。
- 不用
irate()做告警：它只看最后两个点，抖动大且无法回溯，rate()更稳；绘图才考虑irate() - 聚合时不写
by或without：sum(rate(...))会隐式合并所有序列，极易 OOM；务必显式声明维度，如sum by (job) (rate(...)) - 不查未清洗的原始指标：若存在
user_id标签，即使加了{user_id="abc"}，index 仍需遍历全部 postings；应提前用relabel_configs删除或归一化
