PostgreSQL 慢查询怎么排查和优化：从 EXPLAIN 到索引重建的实战教程

很多后端同学遇到接口变慢，第一反应是加机器，其实多数问题先出在 SQL。前阵子我在美国一个做 B2B SaaS 的项目里处理过一个订单列表接口，p95 从 3.8 秒掉到 220 毫秒，真正起作用的不是玄学调参，而是按步骤把慢点找出来。 第一步不要一上来改索引，先把最慢的 SQL 抓准。我通常同时看应用日志、APM 和数据库慢查询日志，确认是单条 SQL 慢，还是接口里有 N+1 查询。很多人只看接口总耗时，结果把时间花在错误方向。先把请求参数、返回行数、执行次数记下来，再进数据库跑 EXPLAIN ANALYZE。 第二步看执行计划，不要只盯总时间。重点看三件事：是不是走了 Seq Scan 全表扫描、Rows 预估和实际值差得大不大、排序和 join 有没有落盘。那次问题里，订单表已经有 created_at 索引，但查询条件是 account_id + status + creat…