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），而日志里是代入值后的完整语句——比对时需人工归一化，不能直接字符串匹配
