PostgreSQL 查询分析器

要解决的具体问题

PostgreSQL 慢查询的定位往往卡在两个地方：EXPLAIN (ANALYZE, BUFFERS) 输出的指标过多，人工筛选成本高；pg_stat_statements 里的执行频率信息又和表扫描模式缺乏关联，导致缺索引这类基础问题难以快速确认。很多团队只能靠运维经验反复试错，而不是基于数据做出判断。

技能如何工作

该技能的核心是把两路数据拼在一起：一是带 BUFFERS 的 EXPLAIN 结果，能看到实际行数、缓冲区命中和排序开销；二是 pg_stat_statements 视图，用来对照同类 SQL 的累计执行代价。

它的典型工作流程可以拆成三步：

1. 采集诊断信息：拉取指定查询的 EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) 输出，并关联 pg_stat_statements 的统计行。
2. 扫描统计定位异常：通过 pg_stat_user_tables 里的 seq_scan 与 idx_scan 计数器，找出顺序扫描占比偏高、且查询经常命中的大表。
3. 生成优化建议：结合执行计划中的 Seq Scan 节点和过滤条件，给出可执行的 CREATE INDEX 语句建议，并借助 HypoPG 扩展在不真正创建索引的情况下验证效果。

适用边界与注意点

• 该技能聚焦查询层优化，不负责数据库实例级别的容量规划，也无法替代对硬件、配置参数（如 shared_buffers）的调整。
• 索引建议依赖统计信息的新鲜度，pg_stat_user_tables 和 pg_stat_statements 的更新周期由 postgresql.conf 中的设置决定，延迟过长可能导致判断偏差。
• HypoPG 模拟出的索引只是可行性参考，上线前仍需在测试环境验证写入性能和存储开销，避免在高并发写入表上引入不必要的维护成本。