技能介绍

要解决的诊断问题

PostgreSQL 性能异常时，DBA 常先面对一堆零散信号：应用说查询慢，监控说 CPU 高，业务又只是觉得“偶发卡顿”。这类问题缺的不是指标，而是把指标放回数据库上下文里的诊断入口。该技能用于在 PostgreSQL 环境里快速回答几个关键问题：当前有哪些会话在运行或等待？哪些表可能产生 IO 或锁压力？慢查询是否集中在某些 SQL？自动 vacuum 是否真的在跟上？

它如何工作

该技能围绕 PostgreSQL 系统目录展开诊断，而不是只读单一指标：

pg_stat_activity：查看后端进程状态、等待事件和活跃会话，定位长时间运行或互相等待的连接。
pg_stat_user_tables：观察用户表的统计信息，辅助判断哪些表更可能成为扫描、膨胀或维护成本集中的热点。
pg_locks：检查锁对象、锁模式和等待关系，识别阻塞链或持锁时间过长的问题。
pg_stat_statements：分析慢查询轨迹，把耗时语句按调用次数、总时间或排序特征聚合出来。
pg_stat_all_tables 的 autovacuum 相关列：检查表的 vacuum / analyze 状态，判断膨胀是否正在被自动维护控制。

实际使用时，建议按这个顺序做交叉验证：先看 pg_stat_activity 与 pg_locks 确认“现在正在发生什么”；再看 pg_stat_user_tables 与 pg_stat_all_tables 判断“哪些表长期积累压力”；最后用 pg_stat_statements 回放“哪些 SQL 更值得优化”。这种从会话、锁、表统计到语句级证据的路径，更适合排查真实性能问题。

适用边界与注意点

它适合作为 PostgreSQL 性能诊断的起点或巡检脚本的底层逻辑，不适合替代完整的可观测性体系。慢查询分析依赖 pg_stat_statements 已启用且已有足够样本；锁诊断只能反映查询时刻的锁关系，历史阻塞可能已经消失；autovacuum 列能提示最近维护情况，但不能单独证明表没有膨胀或索引没有失效。结果应结合延迟、IO、日志、复制和业务负载一起判断。资料中的底层客户端来自 node-postgres，是非阻塞 PostgreSQL 客户端，纯 JavaScript 实现，也可选择原生 libpq 绑定；这类环境差异会影响连接、权限和目录查询行为，排查时需确认账号至少能读取相关系统目录。