要定位执行时长超过 2000ms 的 PostgreSQL SQL 语句，最直接的方法是配置参数 log_min_duration_statement 为 2000，或查询 pg_stat_statements 扩展视图。适用场景为生产环境慢查询排查，风险边界在于开启全量慢日志可能增加磁盘 IO 负担，建议配合日志轮转策略使用。

命令速用版

以下命令可直接在 psql 终端执行，用于快速开启 2000ms 慢查询日志记录。

ALTER SYSTEM SET log_min_duration_statement = 2000;

SELECT pg_reload_conf();

若需查看统计信息而非日志文件，可查询扩展视图：

SELECT query, total_exec_time, calls FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;

为什么会这样

PostgreSQL 默认不记录慢查询日志，需显式配置阈值才能捕获特定耗时的语句。数据库核心参数 log_min_duration_statement 控制日志记录门槛，默认值为 -1 表示关闭记录。当设置该值为 2000 时，任何执行时间超过 2000 毫秒的语句都会被写入日志，同时 pg_stat_statements 扩展可累计统计所有查询的执行耗时，两者结合能覆盖实时日志与历史统计两种排查需求。

分步处理

第一步：检查当前配置状态。执行 SHOW log_min_duration_statement; 若返回 -1 则表示未开启慢查询日志。

第二步：修改配置阈值。执行 ALTER SYSTEM SET log_min_duration_statement = 2000; 将记录门槛设为 2000 毫秒。若需记录所有语句可设为 0，但生产环境不建议。

第三步：重载配置生效。执行 SELECT pg_reload_conf(); 无需重启数据库即可使参数生效。若修改了 postgresql.conf 中的 shared_preload_libraries 则需重启。

第四步：确认日志路径。查询 SHOW log_directory; 和 SHOW log_filename; 确定日志文件存储位置，通常在 data/log 目录下。

怎么验证是否生效

执行一条故意延时的 SQL 语句，例如 SELECT pg_sleep(3); 该语句执行耗时约 3 秒，超过 2000ms 阈值。随后检查数据库日志文件，应能看到包含 duration: 3000.xx ms 字样的日志记录。若使用 pg_stat_statements，查询视图应能看到该语句的 total_exec_time 累计增加。

常见坑

参数冲突风险：若同时设置 log_statement = 'all' 和 log_min_duration_statement，前者优先级更高，会导致记录所有语句而忽略时长阈值，建议仅保留时长限制。

性能开销警告：开启慢查询日志会增加 CPU 和磁盘 IO 开销，高并发场景下建议阈值不要设得过低，避免日志写入拖慢数据库。

日志轮转配置：未配置 log_rotation_age 或 log_rotation_size 可能导致单个日志文件过大，建议设置定期轮转以便排查。

常见问题

修改参数后必须重启数据库吗？

通常不需要重启。使用 ALTER SYSTEM 修改 log_min_duration_statement 后，执行 pg_reload_conf 即可生效，仅当修改 shared_preload_libraries 时才需重启。

日志文件默认存在哪里？

默认通常在数据目录下的 log 子目录中，具体路径可通过 SHOW log_directory 命令查看，文件名格式由 log_filename 参数定义。

pg_stat_statements 和慢日志有什么区别？

慢日志记录超过阈值的每条具体执行语句，适合实时排查；pg_stat_statements 统计归一化后的查询累计耗时，适合发现高频慢查询模式。

参考来源

1. CSDN 博客《PostgreSQL 查询慢？这几个索引问题查了我半天》

2. CSDN 问答《PostgreSQL 日志中如何定位慢查询？_编程语言-CSDN 问答》

3. 博客园《postgres 定位执行慢的 SQL 的方法》

4. CSDN 博客《PostgreSQL 慢 SQL 的定位排查方法例子解析》