PostgreSQL 慢查询操作手册

先说清楚要解决什么

PostgreSQL 的慢查询通常不是单点故障。你能观察到的是 p99 延迟上涨、事务堆积，但真正拖慢业务的原因往往落在几类固定模式上：本该命中索引的查询走了 Seq Scan；统计信息过期导致 planner 选错执行计划；某条高频 SQL 反复全表扫描；或是事务之间的持锁等待把整条链路拖住。这类问题靠裸看一次 EXPLAIN 基本看不出来，需要把执行统计和索引使用情况交叉验证才能下结论。

技能如何工作

手册围绕三张数据来源组织诊断流程：

• pg_stat_statements：按语句维度聚合执行次数、总耗时、缓存命中率与 IO 统计，用来回答"哪类 SQL 累计消耗最多"，而不是"哪条 SQL 刚刚最慢"。
• EXPLAIN ANALYZE 输出解析：逐行读取计划节点，定位高代价节点，把 cost 估算与实际执行时间的差距当作 planner 失准的信号。
• pg_stat_user_indexes：按表和索引维度查看扫描次数与命中情况，判断现有索引是否真的被用上，以及哪些表完全没有索引支撑。

关键步骤大致如下：

1. 从 pg_stat_statements 拉出累计耗时靠前的查询模板；
2. 对目标语句执行 EXPLAIN (ANALYZE, BUFFERS)，找出实际执行时间集中在哪个节点；
3. 对照 pg_stat_user_indexes 检查该表的索引扫描次数，确认是缺索引还是索引没被选中；
4. 结合锁等待信息排查阻塞链，把锁竞争从"疑似原因"变成"确认结论"。

适用边界与注意点

• 它定位的是"哪里慢、为什么慢"，不会替你改 SQL、建索引或调参数，落地修复仍由你决策。
• pg_stat_statements 需要提前在集群中启用并保留足够的历史窗口，样本不足时结论不可靠。
• EXPLAIN ANALYZE 会真实执行语句，对超大表或高频查询要谨慎，建议在备库或低峰期运行。
• 判断索引缺失应依据 pg_stat_user_indexes 的实际使用数据，而不是仅凭 SQL 文本推断，避免建出无人使用的冗余索引。
• 锁竞争部分需要与其他等待事件视图配合，仅凭手册给出的三张表不足以覆盖全部场景。