PostgreSQL log_min_duration_statement 设置为 0 的风险与替代

log_min_duration_statement = 0 会记录每条执行完成的SQL语句，导致日志暴增、I/O压力升高及有效信息被淹没；应按需动态启用，配合合理轮转策略。

log_min_duration_statement = 0 会记录每条 SQL，不只是慢查询

设置 log_min_duration_statement = 0 后，PostgreSQL 会对**每一条执行完成的语句**（包括 SELECT 1、空事务、健康检查 SQL）生成日志行。这在高并发或高频心跳场景下极易导致：日志文件暴增、磁盘 I/O 压力陡升、syslog 或日志轮转服务卡顿，甚至触发磁盘写满告警。

更隐蔽的问题是：日志中混入大量无意义语句，真正需要排查的异常或低效查询反而被淹没，丧失日志的可观测价值。

更安全的替代方案：按需开启，而非全局捕获

用动态方式临时启用，比永久设为 0 更可控：

• 对单个会话启用：SET log_min_duration_statement = 1000（单位毫秒），只影响当前连接，业务逻辑结束即失效
• 对特定用户启用：ALTER USER app_user SET log_min_duration_statement = 500，适用于调试某类应用行为
• 配合 log_statement = 'none' 使用，避免重复记录（log_statement 记所有语句文本，log_min_duration_statement 记带执行时长的摘要，二者同时开等于双倍日志量）

真正需要“全量

语句日志”时，别用 log_min_duration_statement

如果确实要审计或分析全部 SQL（如合规要求、SQL 模式识别），log_min_duration_statement = 0 并非正解——它不记录参数值、不包含绑定变量展开、也不保留客户端上下文（如应用名、IP）。

推荐路径：

• 启用 log_statement = 'all' + log_parameter = on（需 9.2+，且注意密码等敏感字段可能泄露）
• 用 pg_stat_statements 扩展采集执行统计（无需日志 I/O，但不保留原始 SQL 文本，仅归一化后的模板）
• 对关键业务库，在应用层加 SQL 日志钩子（如 JDBC 的 loggerLevel=DEBUG 配合 logUnclosedConnections=true）

监控与兜底：必须配 log_rotation_age 和 log_rotation_size

即使只设为 100 或 500，长期运行仍可能积累大量日志。务必同步配置：

• log_rotation_age = 1d（按时间轮转）
• log_rotation_size = 100MB（按大小轮转）
• log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'（含时间戳，便于定位）

没有轮转机制的日志目录，哪怕只记录 >1s 的语句，在 OLTP 系统上几小时就能占满几十 GB —— 这比设为 0 更危险，因为问题会延迟暴露。