PostgreSQL 查询优化代理

它解决的问题

当一条 SQL 在生产环境变慢时，第一反应往往是加索引。但盲目加索引会带来写入放大、存储膨胀和 planner 成本上升。真正的瓶颈可能出在统计信息过期、JOIN 顺序错误、或索引类型不匹配（例如 JSONB 字段上该用 GIN 而不是 B-tree）。

这个技能要回答的是：如何在不动数据的前提下，先看清楚计划再动手。

核心能力与工作方式

技能围绕 PostgreSQL 自带的两个观测面展开：

• 执行计划采样：通过 EXPLAIN (ANALYZE, ...) 拿到真实执行统计，而不只是 planner 的估算值，包括 actual time、rows、loops 等区分「慢在哪一行」的关键指标。
• 语句级统计：结合 pg_stat_statements 扩展的数据，从「单次执行」跳到「累计负载」视角，判断一条查询是偶发抖动还是高频慢查询。

索引建议的生成分三步走：

1. 解析 EXPLAIN ANALYZE 输出，定位代价最高的节点（通常是全表扫描或嵌套循环）；
2. 用 HypoPG 模拟候选索引，在不实际创建索引的前提下比较计划变化。这一点很关键——PostgreSQL 原生不支持假设索引，HypoPG 通过扩展机制补上了这个缺口；
3. 用 pghintplan 的 hint 指令（如 /*+ IndexScan(...) */）反向验证：强制某个索引路径后计划确实变好，说明索引值得加；强制之后依然慢，说明瓶颈不在索引。

底层通过 pg 驱动（node-postgres）与数据库通信，纯 JavaScript 实现，可选原生 libpq 绑定换取更低延迟。

适用边界与注意点

几个容易踩的坑：

• 统计信息必须先刷新。ANALYZE 没跑过时，planner 的估算值可能严重偏离真实行数，模拟结果就不可信。
• HypoPG 只在单个会话内生效。假设索引不写入系统目录，会话结束即消失；它适合评估，不能替代线上真实索引。
• pghintplan 需要数据库侧配置，且 hint 语法不保证计划一定被采用，planner 仍可能忽略不可行的 hint。
• 技能给出的索引建议只是候选，最终还要结合写入负载、并发场景和磁盘成本权衡，不能直接照搬上线。