PostgreSQL的日志系统里有一个容易被忽略但非常实用的参数：log_min_duration_statement。它的作用非常直接——当一条SQL语句的执行时间超过你设定的毫秒数时，这条语句就会被记录到数据库日志中。这个参数默认值为-1，表示完全关闭慢查询记录功能。如果把值设置为0，则所有执行的语句无论快慢都会被记录，这通常只用于调试环境。更常见的做法是设置一个正整数，比如1000，表示只记录执行时间超过1秒的语句。这种按时间阈值过滤的机制，让DBA能够在繁忙的生产环境中只关注那些真正值得优化的慢查询，避免日志被大量无关的快速查询淹没。
要理解这个参数的价值，需要先知道PostgreSQL在执行语句时会在内部记录起始时间和结束时间。当语句完成后，系统会计算实际耗时，并与log_min_duration_statement进行比较。如果耗时超过设定值，日志系统就会输出一条包含语句文本和执行时间的记录。这个比较过程是异步的，对正常语句执行路径的干扰非常小。不过需要注意的是，参数只记录语句的执行时长，不包括语句进入队列之前的等待时间。如果你的系统存在连接池排队或者锁等待，实际用户感受到的延迟可能比日志中记录的duration要长，排查问题时需要结合其他视图综合判断。
一、参数取值与基础配置方法
先看一下参数的取值类型。在PostgreSQL中，log_min_duration_statement接受整数，单位为毫秒。如果设置为-1，表示不记录任何语句；设置为0，表示记录所有语句；设置为大于0的整数，表示记录执行时间超过该值的语句。例如设置log_min_duration_statement = 250，那么任何执行时间大于250毫秒的SQL都会被记录。这个参数可以在postgresql.conf文件中永久配置，也可以通过ALTER SYSTEM命令在运行时修改，后者不需要直接编辑配置文件。
要查看当前数据库的配置值，可以执行以下SQL：
SHOW log_min_duration_statement;
输出结果会显示类似-1或1000这样的值。如果你希望在会话级别临时调整，可以使用SET命令，但这种方式只对当前会话有效，数据库重启或新会话创建后会恢复为系统默认值。对于全局永久生效，推荐使用ALTER SYSTEM：
ALTER SYSTEM SET log_min_duration_statement = 500; SELECT pg_reload_conf();
执行pg_reload_conf()后，PostgreSQL会重新加载配置文件，不需要重启服务。但要注意，某些参数只在会话开始时读取，修改后已有的连接可能仍沿用旧值。对于log_min_duration_statement，它属于可在会话启动时读取的参数，因此新建立的连接会使用新阈值，而旧连接则不受影响。如果需要所有会话立即生效，需要重新连接或者重启连接池。
另一个需要注意的点是，该参数在超级用户权限下执行ALTER SYSTEM需要相应权限，普通用户无法修改。此外，参数修改后会在数据库日志中留下一条配置变更记录，方便审计和回溯。
二、慢查询日志的格式与字段解读
开启慢查询记录后，PostgreSQL会在日志文件中输出类似下面的内容：
2025-01-12 14:23:45.123 CST [20456] LOG: duration: 1234.567 ms statement: SELECT * FROM orders WHERE customer_id = 12345;
这行日志包含了多个关键字段。最前面是时间戳和会话PID，duration后面的数值表示实际执行时长，单位是毫秒。statement后面则是完整的SQL语句文本。日志格式可以通过log_line_prefix参数定制，例如加上用户名、数据库名、客户端地址等信息，让慢查询日志更具备可诊断性。例如配置：
log_line_prefix = '%t [%p] %u@%d '
这样日志中就会包含用户和数据库信息，方便定位是哪个应用账号发起的查询。需要注意，如果SQL语句中包含参数，默认情况下PostgreSQL只记录语句模板，而不是实际绑定的参数值。要记录实际参数值，需要开启log_parameter_values参数，但这样会增加日志量并可能暴露敏感数据，生产环境需谨慎评估。
除了statement类型的日志，当语句执行超过阈值时，有时还会伴随duration和execute等标记。如果同时开启了log_duration，所有语句的执行时间都会被记录，而不只是慢查询。这会导致日志量急剧增长，通常不建议同时开启，除非在极短时间的性能排查中。相比之下，log_min_duration_statement更加精准，只输出超过阈值的语句，是长期监控慢查询的首选。
三、与相关日志参数的区别与配合
很多开发者容易把log_min_duration_statement与log_statement混为一谈。log_statement控制的是记录哪些类型的语句，可选值包括none、ddl、mod和all。它不关心语句执行时间，只关心语句类型。例如设置为ddl会记录所有数据定义语言，如CREATE、ALTER、DROP等。而log_min_duration_statement只关心时间，不关心类型。两者可以组合使用，比如你希望记录所有DDL语句，同时额外记录执行超过500毫秒的DML语句，那么可以设置log_statement = 'ddl'并且log_min_duration_statement = 500。这样DDL无论执行快慢都会被记录，DML只有超过阈值才会记录。
还有一个参数log_min_error_statement，它记录的是导致错误或异常退出的语句，而不考虑执行时间。这个参数在排查应用报错时很有用。三个参数可以并行开启，但要注意日志量的叠加效应。如果你的系统本身有大量快速查询，同时开启log_statement = 'all'和log_min_duration_statement会导致日志几乎翻倍。因此建议只在需要时打开，并配合日志轮转工具如logrotate或PostgreSQL自带的logging_collector进行压缩归档。
从性能角度分析，记录慢查询本身对系统的影响非常小，因为只发生在语句执行结束后。但在极端情况下，比如阈值设得非常低，导致大量语句被记录，磁盘I/O和日志写入压力可能成为新的瓶颈。通常建议先从较高阈值开始，例如1000毫秒，观察一段时间后再逐步下调，直到能覆盖大多数用户可感知的慢查询。对于OLTP系统，500毫秒往往是一个合理的起点；对于批处理或报表系统，可以放宽到2000毫秒以上。
四、实际应用场景与优化建议
慢查询日志的价值最终体现在问题定位和性能调优上。当你发现数据库中某类操作延迟升高时，可以先检查日志中最近出现的慢查询，筛选出执行时间最长的几条语句，然后通过EXPLAIN ANALYZE分析其执行计划，找出全表扫描、缺少索引或者统计信息过时等问题。例如日志显示一条SELECT语句执行了3000毫秒，执行计划中可能显示Seq Scan on large_table，这提示你需要在该表查询条件列上创建索引。
另一种常见场景是应用发布新版本后突然出现大量慢查询。通过对比日志中语句模板的变化，可以快速定位是新引入的查询逻辑不合理，还是数据量增长导致原计划失效。此时可以利用pg_stat_statements扩展辅助分析，它与慢查询日志互补：前者提供聚合统计，后者提供具体的单次执行明细和实际参数文本。两者结合可以更全面地还原问题发生时的上下文。
不过要注意，慢查询日志并不捕获那些长时间运行但最终被取消的语句，因为语句被取消后可能不会正常触发duration输出。如果你需要追踪被取消或超时的语句，可以结合log_min_error_statement和statement_timeout来记录。另外，如果使用连接池，日志中的会话PID可能对应多个客户端，仅凭PID难以关联到具体业务操作。此时建议在应用层使用唯一标识，例如在SQL注释中加入追踪ID，并在日志中记录该注释，这样能从日志条目反推到业务请求。
总结来说，log_min_duration_statement是一个轻量、精准的慢查询捕获工具。合理设置阈值、结合其他日志参数、配合分析工具和索引优化，你可以在不显著增加系统负担的情况下，持续监控数据库的性能健康状况。建议将阈值调整纳入运维规范，定期回顾慢查询日志，对频繁出现的慢语句主动进行索引或查询重写优化，而不是等问题爆发后再被动处理。
PostgreSQL慢查询log_min_duration_statementSQL日志修改时间：2026-08-19 07:05:07