PostgreSQL 诊断分析器

要解决的问题

PostgreSQL 上线一段时间后，性能问题通常不会自己浮出水面。慢查询只在高峰时段出现，锁等待会拖垮整个连接池，而表膨胀则在不知不觉中让磁盘和缓存越来越紧张。运维人员如果只盯着应用日志，很难判断瓶颈到底在 SQL 本身、并发争用，还是表与索引的物理布局。

技能如何工作

这个技能直接对 PostgreSQL 实例执行诊断查询，围绕三个核心问题展开：

• 慢查询定位：读取 pg_stat_statements 中的聚合统计，找出累计耗时高、调用次数频繁且实际代价与逻辑读取差异明显的语句。
• 锁竞争排查：结合 pg_stat_activity 查看当前会话的状态与等待情况，再对照 pg_locks 分析锁的持有者与等待者，定位阻塞链条。
• 膨胀分析：借助 pgstattuple 检查表与索引元组的物理分布，评估空洞比例，必要时参考 pg_repack 的分析结果判断是否需要重建。

诊断过程分为三步：先采集系统视图的原始指标，再按问题维度归类，最后输出可定位到具体对象（库、表、语句）的结论。

适用边界与注意点

• 依赖 pg_stat_statements 等扩展已经正确安装并完成初始化，否则相关视图可能为空或不存在。
• pgstattuple 与 pg_repack 属于扩展级能力，执行时会对目标表加短暂锁或读取物理页面，建议在低峰期针对单表操作，避免影响线上写入。
• 统计信息存在采样与刷新延迟，看到的可能是历史累计值而非瞬时状态，需要结合时间窗口判断趋势。
• 诊断结果只反映执行计划与物理存储层面的信号，是否属于真实瓶颈仍需结合业务负载确认。