PostgreSQL 性能监控三件套pg_stat_statements、auto_explain 与 pg_overexplain 实战入门【免费下载链接】postgresMirror of the official PostgreSQL GIT repository. Note that this is just a *mirror* - we dont work with pull requests on github. To contribute, please see https://wiki.postgresql.org/wiki/Submitting_a_Patch项目地址: https://gitcode.com/gh_mirrors/po/postgres数据库变慢是新手最常遇到的难题。PostgreSQL 性能监控有一套官方内置的三件套组合拳用 pg_stat_statements 统计谁最慢用 auto_explain 自动抓取执行计划用 pg_overexplain 深度调试计划细节。本文带你快速上手这三个 contrib 扩展从零搭建一条完整的 PostgreSQL 慢查询排查链路。为什么要做 PostgreSQL 性能监控 生产环境中数据库偶发变慢往往查无头绪哪条 SQL 最耗时是索引失效还是统计信息过期高峰期和低谷期的执行计划是否一致手动EXPLAIN一条条排查效率极低。PostgreSQL 自带的三个扩展各司其职覆盖了发现 → 定位 → 深挖全流程扩展核心职责一句话理解pg_stat_statements全库 SQL 执行统计帮你找到最慢的那条 SQLauto_explain超慢查询自动记执行计划慢查询发生时自动拍照pg_overexplain输出更详细的 EXPLAIN 信息给执行计划开放大镜三者源码分别位于 contrib/pg_stat_statements/、contrib/auto_explain/ 和 contrib/pg_overexplain/。第一步pg_stat_statements 快速找出最慢 SQL pg_stat_statements 统计所有 SQL 语句的执行次数、总耗时、行数与共享内存命中情况是 PostgreSQL 性能监控的第一块基石。一键启用步骤在配置文件postgresql.conf中加入shared_preload_libraries pg_stat_statements该配置写法可参考仓库自带的 contrib/pg_stat_statements/pg_stat_statements.conf重启数据库在目标库中创建扩展CREATE EXTENSION pg_stat_statements;启用后打开查询窗口看一眼罪魁祸首SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10; 小贴士该扩展会对相同结构的 SQL参数不同但语句相同自动归并计数因此看到的均值耗时比单条日志更有参考价值。其统计原理可参阅 contrib/pg_stat_statements/pg_stat_statements.c 开头的注释说明完整文档见 doc/src/sgml/pgstatstatements.sgml。第二步auto_explain 自动捕获慢查询执行计划 光知道哪条 SQL 慢还不够还要看它的执行计划。auto_explain 会在语句运行时间超过阈值时自动把执行计划写入服务器日志无需任何人在场操作。最快配置方法shared_preload_libraries pg_stat_statements, auto_explain auto_explain.log_min_duration 2s -- 超过 2 秒才记录 auto_explain.log_analyze on -- 附带真实的运行时信息 auto_explain.log_buffers on -- 附带缓冲区读写信息 auto_explain.log_timing off -- 关闭耗时计时可选之后重启实例即可。再出现超过 2 秒的慢查询时日志里就会自动出现类似这样的计划LOG: duration: 3823.45 ms plan: - Seq Scan on orders (cost0.00..3810.00 rows210000 width24) Filter: (status pending)看到Seq Scan全表扫描问题基本就定位了——多半是缺索引或统计信息过期。常用参数一览源码中定义的完整 GUC 见 contrib/auto_explain/auto_explain.c参数作用auto_explain.log_min_duration记录阈值单位 ms 或秒默认 -1关闭auto_explain.log_analyze是否附带实际运行时间auto_explain.log_buffers是否输出缓冲区统计auto_explain.log_wal是否输出 WAL 写入统计auto_explain.sample_rate采样率高并发下可设为 0.1 降低开销auto_explain.log_format支持 text / json / yaml / xml方便程序解析详细文档参见 doc/src/sgml/auto-explain.sgml。第三步pg_overexplain 深度调试执行计划 pg_overexplain 为 EXPLAIN 增加两个调试选项debug输出计划树内部结构range_table输出范围表信息专治计划看起来正常但行为诡异的疑难杂症。两条命令上手CREATE EXTENSION pg_overexplain; -- 查看计划树的内部节点与祖先关系 EXPLAIN (DEBUG) SELECT * FROM t WHERE a 1; -- 额外查看 range table表别名解析的关键信息 EXPLAIN (RANGE_TABLE) SELECT * FROM t;它同样注册了扩展 EXPLAIN 选项实现见 contrib/pg_overexplain/pg_overexplain.c 中的RegisterExtensionExplainOption还能与 auto_explain 配合通过auto_explain.log_extension_options debug, range_table让自动抓取的计划也带上调试信息组合示例可参考 contrib/auto_explain/sql/extension_options.sql。官方文档见 doc/src/sgml/pgoverexplain.sgml。实战工作流三件套如何组合排查 一条完整的排查路径只需四步发现定期用 pg_stat_statements 按mean_exec_time排序锁定 Top 10 慢语句定位让 auto_explain 在慢查询发生时自动落日志避免复现即消失复现对可疑 SQL 手动执行EXPLAIN (ANALYZE, BUFFERS)深挖计划反常时使用EXPLAIN (DEBUG)/EXPLAIN (RANGE_TABLE)检查内部结构。⚠️ 注意pg_stat_statements 与 auto_explain 都需要shared_preload_libraries预加载后重启才生效pg_overexplain 则是普通扩展CREATE EXTENSION立即可用。源码与文档导航 想深入阅读实现细节可以从以下入口开始pg_stat_statements 核心实现contrib/pg_stat_statements/pg_stat_statements.cauto_explain 钩子逻辑ExecutorStart/Run/End 注入点contrib/auto_explain/auto_explain.cpg_overexplain 扩展选项注册contrib/pg_overexplain/pg_overexplain.c三个扩展的测试用例最佳活教材contrib/pg_stat_statements/sql/、contrib/auto_explain/sql/、contrib/pg_overexplain/sql/官方文档源文件doc/src/sgml/pgstatstatements.sgml、doc/src/sgml/auto-explain.sgml、doc/src/sgml/pgoverexplain.sgml总结PostgreSQL 性能监控不必依赖昂贵的商业工具pg_stat_statements回答谁最慢auto_explain回答它为什么慢自动留证pg_overexplain回答计划内部到底发生了什么。三者全部源自官方 contrib 目录零成本、低侵入。先跑通本文的流程你就能拥有一条可落地的慢查询排查流水线 。【免费下载链接】postgresMirror of the official PostgreSQL GIT repository. Note that this is just a *mirror* - we dont work with pull requests on github. To contribute, please see https://wiki.postgresql.org/wiki/Submitting_a_Patch项目地址: https://gitcode.com/gh_mirrors/po/postgres创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考