我来给你拆解下这个问题的核心，以及对应的应对方案——开启log_min_duration_statement=0确实会对PostgreSQL的性能产生一定影响，但具体的损耗程度取决于你的系统负载、存储配置这些细节，下面分情况说明：

一、性能损耗的核心原因 #

当你把这个参数设为0时，PostgreSQL会记录每一条执行的SQL语句及其耗时，这会带来两个关键开销：

• 磁盘I/O压力陡增：所有SQL日志都会持续写入磁盘（不管是本地日志文件还是远程日志服务），如果你的生产系统QPS很高（比如每秒数千次以上查询），磁盘的写入IOPS会被占满，尤其是用HDD的话，很容易引发磁盘瓶颈，进而拖慢整个数据库的响应速度。
• CPU额外消耗：PostgreSQL需要为每条SQL做日志格式化、写入流程的处理，高并发场景下这部分CPU开销会被放大，可能导致数据库服务器的CPU使用率明显上升，间接影响查询的执行效率。

二、降低性能影响的优化手段 #

如果必须开启全量日志来定位偶发的耗时问题，你可以通过这些方法把损耗降到最低：

• 用高速存储存日志：把日志目录挂载到SSD上，或者临时使用内存文件系统（注意重启会丢失日志，仅适合短期排查），能大幅提升日志写入的速度。
• 配置异步日志写入：确保logging_collector=on，把log_destination设为csvlog，同时开启log_truncate_on_rotation并设置合理的log_rotation_size控制日志文件大小；另外可以临时设置log_flush_on_sync=off（注意：极端情况下系统崩溃可能丢失最后几条日志，适合临时排查场景）。
• 缩小日志记录范围：既然你的问题集中在DML语句，不用记录所有SQL，改成设置log_statement='mod'，这样只会记录INSERT/UPDATE/DELETE等修改类语句，日志量会大幅减少，开销也随之降低。
• 临时开启，用完即关：毕竟是排查偶发问题，建议在系统低峰期开启，或者只运行几个小时拿到足够的异常日志后，立刻恢复原配置，避免长期影响生产性能。

三、更轻量的替代排查方案 #

其实除了全量日志，还有一些开销更小的方法能定位问题：

• 启用auto_explain模块，设置auto_explain.log_min_duration为你认为异常的阈值（比如100ms），只记录慢查询的执行计划和耗时，这样既能捕获到异常语句的细节，又不会产生全量日志的高额开销。
• 同步监控系统层面的指标：比如CPU使用率、内存占用、磁盘IO负载、数据库连接数、锁等待情况，偶发的耗时突增有时候是系统资源瓶颈或者锁冲突导致的，不一定完全是SQL本身的问题。

内容的提问来源于stack exchange，提问作者Ratatouille