17370845950

log_min_duration_statement 是 PostgreSQL 记录慢 SQL 文本的配置参数，仅记录语句、耗时等元信息，不记录执行计划；设为 -1（默认）不记录，0 全记录（不推荐），1000 则记录 ≥1s 的语句。

log_min_duration_statement 是什么，它不记录执行计划

log_min_duration_statement 是 PostgreSQL 的一个配置参数，作用是把运行时间超过指定毫秒数的 SQL 语句写入服务器日志。它只记录语句文本、执行时长、开始时间、用户、数据库等元信息，不会记录执行计划、绑定参数值、实际行数或 I/O 统计。

常见误用是以为开了它就能替代 pg_stat_statements——其实两者定位完全不同：log_min_duration_statement 是“日志快照”，pg_stat_statements 是“聚合统计”。

• 设为 1000：所有 ≥1s 的语句进日志，但每条都独立记一行，无去重、无累计调用次数
• 设为 0：所有语句都记，日志爆炸，不推荐生产环境长期开启
• 设为 -1（默认）：完全不记录执行时长类日志，只记 ERROR/WARNING 等级别事件

pg_stat_statements 必须手动启用且需重启或 reload

pg_stat_statements 是一个扩展模块，不是开个参数就自动生效。它需要两步才能真正采集数据：

• 在 postgresql.conf 中添加 shared_preload_libraries = 'pg_stat_statements'（注意必须在 shared_preload_libraries，不能只写在 session 级）
• 重启 PostgreSQL 或执行 SELECT pg_reload_conf()（但后者仅对已加载的库生效，首次启用仍需重启）

启用后，它会按 queryid 对归一化后的语句做聚合：相同结构（忽略字面量）、相同参数类型、相同 plan hash 的语句算一条。这意味着 SELECT * FROM users WHERE id = 1 和 SELECT * FROM users WHERE id = 2 会被合并统计。

二者结合的关键：用 log_min_duration_statement 定位慢查询，再用 pg_stat_statements 查模式级趋势

单独看日志只能知道“某次执行慢”，单独看 pg_stat_statements 只能看到“平均很慢”或“调用频繁”。二者联动才有效：

• 当发现某条日志里出现 duration: 8423.522 ms，先复制该 SQL，用 EXPLAIN (ANALYZE, BUFFERS) 手动复现，确认是否真有性能问题
• 再去查 pg_stat_statements，看这条语句的 mean_time、calls、total_time 是否也异常——如果 mean_time 正常但某次突增，可能是数据倾斜或锁等待；如果 mean_time 持续高，则大概率是索引缺失或写法问题
• 特别注意 pg_stat_statements 默认只保留最多 5000 条语句（由 pg_stat_statements.max 控制），高频小查询可能被挤掉，导致“日志里能查到，但 pg_stat_statements 里找不到”

容易被忽略的权限与清理陷阱

pg_stat_statements 的视图默认只对超级用户和 pg_read_all_stats 角色可见。普通应用用户查不到，连 SELECT * FROM pg_stat_statements 都会报 permission denied。

日志和统计还存在清理不同步的问题：

• pg_stat_statements 不会自动清理旧数据，需定期执行 SELECT pg_stat_statements_reset()（清空全部）或手动 DELETE 过期项（需先 CREATE EXTENSION IF NOT EXISTS pg_stat_statements 并确保版本支持）
• log_min_duration_statement 产生的日志文件不会自动轮转，得靠外部工具（如 logrotate）或 PostgreSQL 自带的 logging_collector + log_rotation_age 配合
• 若应用大量使用 prepared statement，pg_stat_statements 中的 query 字段显示的是原始 prepare 语句（含 $1, $2），而日志里是代入值后的完整语句——比对时需人工归一化，不能直接字符串匹配