CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT calls, total_exec_time FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 5;

log_min_duration_statement 设成 1000 后日志里几乎没记录,可接口 P99 已经两秒多,找不出慢在哪。先别急着动参数,把报错原文和时间点记下来,顺序反了容易白折腾。

原因不复杂,慢在多次快查询累加或锁等待上,单条执行时间没超过阈值,日志就不会写,只看日志会被误导,得看统计视图里的累积耗时。

围绕「PG 慢查询定位」排查时,命令行跑一遍比在面板里点十次有用,面板会替你做掉不少隐式操作。改完隔一天再看一次,当场正常不代表能稳住。

测试环境和线上的差别,往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点,跟发布、备份、任务执行的时刻排一排,能省掉一半功夫。

处理上按这个顺序:装好 pg_stat_statements 扩展,并确认视图里能查到数据;按累积耗时排序,找出总量最高的那几条语句;对排在前面的几条单独跑执行计划,看实际行数和预估差多少。

改完只确认一件事:能排累积耗时前几名,改完 P99 从两秒降到三百毫秒以内。

作者 9823189