PostgreSQL 性能操作手册

诊断对象：那些“说不清慢在哪”的 PostgreSQL 问题

当数据库出现响应变慢、事务堆积、资源占用异常时，仅靠 pg_stat_database 这类粗粒度指标往往无法定位根因。你需要穿透到会话级别、语句级别，甚至物理存储层面，回答三个核心问题：

• 哪些 SQL 正在消耗资源？
• 它们卡在了哪里——是等锁、等 IO，还是在反复执行却没走索引？
• 是否存在表或索引膨胀，导致扫描成本虚高？

这些问题的答案，散落在 pg_stat_statements、pg_stat_activity、pg_locks 等系统视图中，但手动拼凑查询、解读结果、生成报告既耗时又容易遗漏关键线索。

技能如何工作：从指标采集到决策依据

该技能以操作手册的形式，封装了一套结构化的诊断流程，覆盖从数据采集到优化建议的全链条。

核心步骤包括：

• 调用 pg_stat_statements 聚合执行统计，识别 TOP 慢查询；
• 结合 pg_stat_activity 与 pg_locks，分析当前会话状态、锁等待关系与阻塞源；
• 使用 pgstattuple 扫描表物理结构，量化 freespace、dead_tuples 等膨胀指标；
• 对关键查询生成 EXPLAIN (ANALYZE, BUFFERS) 报告，还原执行计划与实际 I/O 行为；
• 输出结构化诊断结果，包含问题定位、影响范围与建议动作（如索引优化、锁冲突解决、VACUUM 策略调整）。

整个过程不依赖外部代理或侵入式探针，全部通过标准 SQL 与系统视图完成，适合在生产环境按需触发。

适用边界与注意点

• 依赖 pg_stat_statements 扩展，需在 shared_preload_libraries 中预加载，且 track_activities 等参数需开启；
• 诊断结果受采样窗口与统计刷新策略影响，瞬时问题可能被遗漏；
• pgstattuple 扫描大表会产生 IO 开销，建议在低峰期执行或限制扫描范围；
• 建议输出需结合业务上下文解读，例如慢查询是否为高频事务、锁等待是否影响核心链路；
• 不替代数据库参数调优，仅提供可观测性层面的诊断支持。