PostgreSQL log_min_duration_statement 如何设置合理阈值

log_min_duration_statement 是 postgresql 中控制慢查询日志记录阈值的参数（单位毫秒），设为 0 会记录所有语句，但生产环境禁用——易致日志爆炸、I/O 压力剧增、磁盘耗尽甚至拖慢查询。

log_min_duration_statement 是什么，为什么不能随便设成 0

log_min_duration_statement 是 PostgreSQL 的一个配置参数，单位是毫秒，表示「只记录执行时间超过该阈值的 SQL 语句」。设为 0 确实会记录所有语句，但生产环境几乎从不这么干——日志量爆炸、I/O 压力陡增、磁盘可能被撑爆，甚至影响查询响应本身。

真正要问的不是「能不能设 0」，而是「哪些慢查询值得被盯住」。这取决于你的业务节奏、数据库负载特征和可观测能力。

常见业务场景下的推荐阈值范围

没有全局最优值，但可以按典型负载参考：

• 高并发 OLTP（如电商订单、API 后端）：100～500 ms。这类系统对延迟敏感，>100ms 的单条语句已可能拖累整体吞吐
• 中等负载报表/后台任务：1000～5000 ms（1～5 秒）。允许复杂聚合，但持续 >5 秒需介入
• 数据同步或 etl 批处理：10000（10 秒）起跳。重点看是否稳定，而非绝对时长
• 刚上线或性能排查期：临时设为 100，收集 24 小时后用 pg_stat_statements 分析真实分布，再回调

别只看 duration，配合 log_statement 和 log_lock_waits

单独依赖 log_min_duration_statement 容易漏掉关键问题：

• 短但高频的锁等待？得开 log_lock_waits = on，否则看不到 LockWait 类错误
• 计划突变或隐式类型转换？需要 log_statement = 'mod' 或 'ddl' 捕获 DML/DDL，而不是只等它变慢
• 想查某条语句为何慢？先确认 log_min_duration_statement 是否覆盖了它，再结合 log_min_Error_statement = error 看是否因报错提前退出

这些参数是组合拳，不是单点开关。

动态调整与验证是否生效

修改后必须 reload（不是 restart），且要注意作用域：

• 在 postgresql.conf 中改完，运行 select pg_reload_conf();
• 用 ALTER SYSTEM SET log_min_duration_statement = 500; 后也需 reload
• 验证是否生效：SHOW log_min_duration_statement; —— 注意返回值是整数，若显示 -1 表示「关闭日志」，0 才是「记录全部」
• 测试写一条慢 SQL：SELECT pg_sleep(0.6);（600ms），看日志里是否出现对应行；如果没出现，检查 log_destination、logging_collector 是否开启，以及日志路径权限

最容易被忽略的是：修改配置后忘记 reload，或者误以为 SET 会话级命令能影响日志（它不能，该参数仅支持 postmaster 级别）。