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～500ms。这类系统对延迟敏感，>100ms 的单条语句已可能拖累整体吞吐 - 中等负载报表/后台任务：
1000～5000ms（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 级别）。
