log_min_duration_statement 是 postgresql 唯一控制慢查询日志的配置项，单位毫秒，设为-1关闭、0记录所有语句；它仅作用于执行耗时，不捕获解析/绑定等阶段，且需配合 pg_reload_conf() 生效。
log_min_duration_statement 是 PostgreSQL 唯一有效的慢查询日志开关
PostgreSQL 没有 min_duration 这个配置项，它只存在于某些客户端工具或监控插件里；真正控制“多慢才记日志”的，只有 log_min_duration_statement。设成 -1 表示关闭，0 表示记录所有语句（含秒级以下），单位是毫秒。
常见错误现象：
— 修改了不存在的 min_duration，日志毫无变化
— 设成 1000 却发现 SELECT now() 也被记了——因为没关掉 log_statement 或 log_min_error_statement，它们会绕过时长判断
-
log_min_duration_statement只影响普通执行耗时，不捕获解析、绑定、网络延迟等环节 - 若同时开启
log_statement = 'all'，所有 SQL 都会进日志，log_min_duration_statement形同虚设 - 该参数需在
postgresql.conf中设置并pg_reload_conf()生效，改完不 reload 就等于没改
如何避免误记大量轻量查询
默认值 -1 关闭日志，但上线后常有人直接设成 100 或 500，结果日志暴涨、磁盘撑爆。这不是配置错了，而是没结合实际负载过滤。
- 先用
pg_stat_statements查真实慢点：SELECT query, total_time, calls FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10 - 观察 P95 耗时分布，把
log_min_duration_statement设为略高于该值（比如 P95 是 82ms，设成100） - 搭配
log_line_prefix = '%m [%p] %q%u@%d '，加上时间、进程号、用户和库名，方便后续 grep 过滤 - 别在生产库长期开
log_statement = 'mod'，它会把 INSERT/UPDATE/DELETE 全记下，哪怕只花 0.1ms
log_min_duration_statement 对性能的影响很轻，但日志写入本身可能卡住 backend
这个参数本身不增加执行开销：PostgreSQL 只在语句结束时比对一次耗时，不插桩、不计时器。真正拖慢的是日志落盘行为。
- 当日志输出目标是文件（
logging_collector = on），且磁盘 I/O 繁忙时，backend 进程会阻塞在 write() 上，表现为偶发的ClientWrite等待事件 - 用
syslog或csvlog格式可缓解，但需额外运维 syslog daemon - 更稳妥的做法是设高一点阈值（如
500），再配合log_temp_files = 0抓临时文件暴增问题——这两者加起来比盲目压低log_min_duration_statement更有效
注意 log_min_duration_statement 不记录错误语句的完整上下文
如果一条 SQL 因锁超时或唯一冲突失败，只要执行时间没超阈值，就不会进 slow log。而这类错误往往才是性能瓶颈源头。
-
log_min_error_statement = error才能捕获失败语句，但它不带耗时，也不区分是否“慢” - 想同时抓“慢”和“错”，得组合配置：
log_min_duration_statement = 1000+log_min_error_statement = error+log_error_verbosity = verbose - verbose 模式下，错误日志会包含 query string 和参数值（若未被
log_statement截断），但要注意敏感信息泄露风险
最易被忽略的一点：日志里的时间戳是语句**结束时刻**，不是开始时刻。所以两个连续日志之间的时间差，不能直接当成空闲间隔——中间可能夹着一个没被记录的快速语句，也可能压根没执行。
