PostgreSQL 性能诊断

要解决什么问题

线上 PostgreSQL 常见的三类性能故障往往互相掩盖：少数几条 SQL 吃掉大量 CPU；某张大表缺少合适索引而退化为顺序扫描；某个长事务或锁等待拖住整个连接池。只看应用日志很难区分这三者，而一旦打开 pg_stat_statements、pg_stat_user_tables 等系统视图，线索又分散在多个地方，需要人工拼凑。

技能如何工作

PostgreSQL 性能诊断 把分析流程组织在系统统计视图周围：

• 慢查询归因：读取 pg_stat_statements 的执行统计，按总耗时或调用次数排序，找出真正昂贵的语句，而不是只看平均耗时。
• 表级行为：结合 pg_stat_user_tables 观察扫描方式、元组读写与死元组情况，判断是否出现全表扫描或高频更新。
• 执行计划核对：对候选语句跑 EXPLAIN ANALYZE，把计划里各节点的实际耗时与统计视图的结论相互印证。
• 索引缺口识别：通过 pg_stat_user_indexes 检查索引使用情况，找出从未被命中或明显缺失的索引。
• 锁竞争检测：联动 pg_locks 与 pg_stat_activity，定位持锁等待的会话及其阻塞链。

底层依赖 Node.js 的非阻塞 PostgreSQL 客户端 node-postgres，纯 JavaScript 实现，可选原生 libpq 绑定。

适用边界与注意点

• pg_stat_statements 需要在库中安装相应扩展，统计是累计值，重启后归零，对比时要先确定时间窗口。
• 索引建议来自统计信息推导，仍需用 EXPLAIN 验证，避免盲目加索引拖慢写入。
• 锁分析只是当前时刻的快照，间歇性阻塞需要多次采样才能抓到。
• 结论的精度依赖统计视图捕获的样本量，短查询或低频语句可能不足以支撑判断。