不一定值得——高call_count仅说明执行频繁，单次快（avg_ms小）通常因逻辑简单、命中缓存或走索引；应重点关注单次耗时高（avg_ms＞10ms）或总耗时占比大的语句。
pg_stat_statements 里 call_count 高但 total_time 低的 SQL 值得优化吗？
不一定值得——高 call_count 只说明执行频繁，但单次快（total_time / call_count 小）往往意味着逻辑简单、命中缓存或走索引。真要盯的是「单次耗时高」或「总耗时占比大」的语句。
实操建议：
- 优先算
total_time / calls（平均耗时），> 10ms 的才列入慢 SQL 初筛 - 用
total_time排序看“总时间大户”，它们哪怕只调用几次，也可能拖垮整体响应 -
call_count单独排序容易误伤SELECT 1、健康检查 SQL 这类本该轻量的语句
如何用 pg_stat_statements 快速定位真实慢 SQL？
直接查视图时别只 ORDER BY total_time DESC，那会把大事务里的长耗时语句埋没；要加权重、过滤噪声。
实操建议：
- 排除自动解析语句：
WHERE query NOT LIKE 'EXPLAIN%'和NOT LIKE 'DEALLOCATE%' - 聚焦用户业务 SQL：
WHERE calls > 10 AND total_time > 10000（单位 ms，即总耗时超 10 秒） - 加平均耗时列：
ROUND(total_time::numeric / NULLIF(calls, 0), 2) AS avg_ms，再按此排序 - 示例查询片段：
SELECT query, calls, total_time, ROUND(total_time/calls, 2) AS avg_ms FROM pg_stat_statements WHERE calls > 10 AND total_time > 10000 ORDER BY avg_ms DESC LIMIT 5;
total_time 包含哪些开销？为什么它可能远大于 EXPLAIN ANALYZE 的 execution time？
total_time 是从 PostgreSQL 后端收到请求到返回结果的完整耗时，包含网络、锁等待、WAL 写入、缓冲区刷盘等所有环节，不是纯执行计划耗时。
常见偏差原因：
- 锁竞争：另一事务长期持有行锁，当前 SQL 在
waiting状态的时间全算进total_time - IO 延迟：shared_buffers 不够，频繁读磁盘，
EXPLAIN ANALYZE不体现磁盘寻道时间 - 并发挤占：高并发下 CPU 调度延迟、上下文切换开销被计入
- 注意：
pg_stat_statements默认不统计触发器、函数内部语句（除非开启track_activity_query_size和细粒度配置）
call_count 为 0 或 total_time 极小但 SQL 明显卡顿？可能是统计被重置或未启用
pg_stat_statements 不是永久存储，数据在服务器重启、手动 pg_stat_statements_reset() 或共享内存溢出时会清零。另外，它默认不收集所有 SQL。
排查步骤：
- 确认插件已加载：
SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements'; - 检查是否启用：
SHOW pg_stat_statements.track;—— 必须是top或all，不能是none - 验证统计是否活跃：
SELECT count(*) FROM pg_stat_statements WHERE calls > 0;若为 0，说明没采集到任何语句 - 注意：RDS/云数据库常默认关闭该插件，需进控制台手动开启并重启实例
实际分析时最易忽略的点是——pg_stat_statements 统计的是「归一化后」的 SQL 模板（参数被 ? 替换），你看到的 query 字段可能掩盖了具体值导致的执行计划突变。真要定位某次异常，得结合 log_min_duration_statement 日志对齐时间戳。
