首先通过监控发现长查询，再结合执行计划分析与索引优化。利用 pg_stat_statements、pg_stat_activity 和日志记录识别耗时 SQL，使用 EXPLAIN (ANALYZE, BUFFERS) 分析执行瓶颈，检查是否缺失索引、统计信息不准或存在全表扫描。根据分析结果添加复合索引、重写低效 SQL、拆分复杂查询、调整 work_mem 参数或启用分区表。最后通过定期 ANALYZE、VACUUM 和监控索引使用率维持性能，并设置 statement_timeout 防止异常查询影响系统稳定。
在 PostgreSQL 中，长时间运行的查询（long-running query）会影响数据库整体性能，造成资源争用、连接堆积甚至服务响应变慢。优化这类查询需要从识别、分析到调优的系统性方法。下面介绍如何定位和优化 PostgreSQL 中的长查询。
监控与识别长查询
要优化长查询，首先要能发现它。PostgreSQL 提供了多种方式来识别执行时间过长的 SQL。
- 使用 pg_stat_statements 扩展：启用该扩展后可统计所有 SQL 的执行次数、总耗时、平均耗时等。通过查询该视图，快速找出最耗时的 SQL。
-
查询 pg_stat_activity 视图：实时查看当前正在执行的查询，结合
now() - query_start判断执行时间是否异常。 -
设置日志记录：在 postgresql.conf 中配置
log_min_duration_statement = 1000（单位毫秒），记录超过 1 秒的语句，便于后续分析。
分析执行计划（EXPLAIN）
找到可疑查询后，使用 EXPLAIN (ANALYZE, BUFFERS) 获取实际执行计划，这是优化的核心步骤。
- 关注成本高、耗时长的节点：如 Nested Loop、Seq Scan（全表扫描）、Hash Join 等，尤其是出现在外层循环中的操作。
- 检查是否走索引：如果本应走索引却执行了全表扫描，可能是索引缺失、统计信息不准或查询条件无法利用索引。
-
注意 rows 字段偏差：预估行数（rows）与实际行数（actual rows）差异大，说明统计信息不准确，可运行
ANALYZE table_name;更新。 - 查看 Buffers 使用情况：若 shared hit 较少、read 较多，说明数据未命中缓存，可能需调整 work_mem 或增加索引减少扫描量。
常见优化手段
根据执行计划反馈，采取针对性措施提升查询效率。
- 添加合适的索引：为 WHERE、JOIN、ORDER BY 涉及的列创建复合索引，注意索引顺序和覆盖索引的使用。
- 拆分复杂查询：将大查询拆成多个小查询，或使用临时表缓存中间结果，避免重复计算。
-
调整配置参数：适当增大
work_mem可提升排序和哈希操作性能；但需避免设置过高导致内存溢出。 -
重写低效 SQL：避免在 WHERE 条件中对字段做函数处理（如
WHERE to_char(date) = '2024-01'），这会阻止索引使用。改用范围查询更高效。 - 分区表处理大数据集：对按时间或范围划分的大表进行分区，可显著减少单次查询扫描的数据量。
定期维护与预防
优化不是一次性的，需建立持续监控和维护机制。
- 定期运行 ANALYZE 和 VACUUM：确保统计信息准确，防止执行计划退化。
-
监控索引使用率：通过
pg_stat_user_indexes查看哪些索引从未被使用，及时清理冗余索引减轻写入负担。 -
设置语句超时：对应用层查询设置
statement_timeout，防止意外长查询拖垮系统。
基本上就这些。通过监控发现、执行计划分析、索引优化和定期维护，可以有效控制和改善 PostgreSQL 中的长查询问题。关键在于养成定期审视慢查询日志的习惯，把性能优化融入日常运维中。
