PostgreSQL 查询计划解释器

要解决的问题

当慢查询出现时，很多团队的第一反应是给条件加索引。但在 PostgreSQL 里，EXPLAIN ANALYZE 的实际输出往往比直觉更复杂：同样的谓词可能因为统计信息、选择率、缓存状态而走完全不同的路径。只看一段 JSON 或文本计划，很难判断到底是顺序扫描过多、索引选择性不足，还是缓冲命中率偏低导致回表频繁。

技能如何工作

这个技能面向的是已经能拿到计划输出，但需要更稳定解读的场景。它以 EXPLAIN ANALYZE 结果为基础，结合以下数据源做归因：

• pg_stat_statements：用于把单次计划里的耗时信息，放到更长期的执行统计语境中看，而不是只看一次采样。
• auto_explain：用于补齐那些“没有主动 EXPLAIN”的语句，把计划纳入统一复盘范围。

在解读过程中，技能关注几类常见瓶颈与可操作建议：

• 顺序扫描（Sequential Scan）是否是主要成本来源：区分“小表全扫合理”与“大表全扫异常”。
• 索引建议（借助 HypoPG）：用于在不立刻创建真实索引的前提下，验证“如果存在某种索引，计划是否会改变”。
• 缓冲缓存命中率（Buffer Cache Hit Ratio）：用于判断问题更偏“存储/IO”还是“执行策略”。

适用边界与注意点

• 该技能解决的是计划解读与优化方向判断，不会替代数据库参数治理、数据模型调整或容量规划。
• HypoPG 相关的索引建议属于假设性验证：即使计划看起来变好，仍需在测试环境验证写入开销、维护成本与实际收益。
• pg_stat_statements 与 auto_explain 都依赖相应扩展/模块的正确加载与配置；数据缺失时，结论应相应收敛。
• 计划输出会受统计信息与数据分布影响，建议在代表性数据与负载下复核结论。