PostgreSQL 慢查询与执行计划分析（EXPLAIN / pg_stat_statements）

PostgreSQL 的性能分析思路和 MySQL 类似，但工具链有自己的特色：pg_stat_statements + EXPLAIN ANALYZE 是黄金组合。

一、开启 pg_stat_statements

CREATE EXTENSION pg_stat_statements;   -- 需提前在 shared_preload_libraries 中加载

postgresql.conf：

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all

二、定位最慢的 SQL

SELECT query, calls, total_exec_time, mean_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

total_exec_time 高的就是重点优化对象。

三、用 EXPLAIN ANALYZE 看计划

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 10;

关键看：

• Seq Scan：全表扫描，大表上通常是性能隐患，应考虑建索引。
• Index Scan / Index Only Scan：走了索引，理想。
• Bitmap Heap Scan：先位图再回表，介于两者之间。
• cost / actual time：对比“预估成本”和“实际耗时”，偏差大说明统计信息不准，需 ANALYZE table;。

四、索引优化

CREATE INDEX idx_orders_user ON orders(user_id);
CREATE INDEX idx_orders_ctime ON orders(created_at);

• PG 默认 不自动使用 低选择度索引（如 WHERE status=1），优化器可能选 Seq Scan，属正常。
• 联合索引注意列顺序；可用 CREATE INDEX ... (a) WHERE active 建部分索引减少体积。

五、统计信息

ANALYZE orders;                  -- 更新统计信息
VACUUM ANALYZE orders;          -- 回收空间 + 更新统计

小结

PG 慢查询 = pg_stat_statements 找 Top SQL → EXPLAIN ANALYZE 看真实计划 → 建索引 / ANALYZE 更新统计。注意 Seq Scan 不一定坏，要看表大小和过滤条件。