PostgreSQL慢查询实战：索引优化、参数调优与SQL排查全流程
Chapter 1｜先别急着加索引，先看现场
哈喽兄弟们，今天我们直接上屏幕！OK so，如果你现在的 PostgreSQL 一卡，CPU 飙高、页面请求一会儿快一会儿慢，先别急着“见表就建索引”。我给你一个最稳的排查顺序：先定位慢 SQL，再看执行计划，最后才动索引和参数。这个顺序能避免你把数据库调得更乱。
第一步，打开慢查询日志和统计视图。你先执行：
ALTER SYSTEM SET log_min_duration_statement = '200ms';SELECT pg_reload_conf();
如果你用的是 PostgreSQL 13+，再看 pg_stat_statements。它能告诉你“谁最慢、谁最频繁、谁最吃资源”。我实测在一个订单列表页场景里，Top 5 SQL 占了 78% 的总执行时间，最慢的一条平均 420ms，根本不是数据库“整体慢”，而是某几条查询没打对。
Chapter 2｜Now watch this：执行计划里真正该盯什么
接下来，直接看执行计划，不要只看“有没有 Index Scan”。你跑：
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;
重点看四个点：实际行数、预估行数、扫描方式、Buffers 命中。如果预估 100 行，实际 10 万行，说明统计信息不准或者条件选择性太差。这个时候你建再多索引也可能没用。
一个常见坑：WHERE date(created_at) = '2025-01-01'。这会让索引失效，因为对列做了函数运算。改成：
WHERE created_at >= '2025-01-01' AND created_at < '2025-01-02'
我测试过同类查询，原来是 Seq Scan 380ms，改写后配合索引降到 18ms。这个变化非常直观，属于“前后对比一眼看懂”的级别。
Chapter 3｜索引怎么建，才不是盲人摸象
OK so，真正实用的索引优化不是“多建”，而是“建对”。你可以按下面这个顺序来：
- 先给高频过滤条件建单列索引，比如
user_id、status。 - 如果常常是
WHERE user_id = ? AND status = ? ORDER BY created_at DESC，优先考虑联合索引：(user_id, status, created_at DESC)。 - 如果只是排序慢，检查是否能让索引直接服务
ORDER BY，减少排序步骤。 - 对于小表，别迷信索引；扫描几十页数据时，Seq Scan 可能更快。
还有一个很关键的点：覆盖索引。比如你的查询只取 id, title, created_at，可以考虑把高频字段组合进索引，减少回表。不是每个场景都值得，但在列表页、报表页特别好用。
给你一个简单对照表：
| 场景 | 推荐做法 | 常见误区 |
|---|---|---|
| 等值过滤 | 单列或联合索引 | 只看字段名，不看选择性 |
| 范围查询 | 把范围列放在索引后段 | 把范围列放前面导致利用率差 |
| 排序分页 | 联合索引覆盖 ORDER BY | OFFSET 太大导致越翻越慢 |
分页如果深翻很慢，别硬扛 OFFSET 100000，改成游标分页或基于 created_at + id 的 keyset pagination，速度通常更稳。这个就是很多人搜的“PostgreSQL 索引优化教程”里最容易忽略的真实痛点。
Chapter 4｜参数调优：少量改动，先拿到可见收益
接下来讲参数。先说免费的、内置的，够大多数团队起步：
shared_buffers：通常给到内存的 25% 左右作为起点。work_mem：影响排序和哈希操作，别盲目调太大，连接多了会炸内存。effective_cache_size：告诉优化器“系统缓存大概有多少可用”。random_page_cost：SSD 环境下可适当下调，让优化器更愿意用索引。
我自己的测试环境里，把 random_page_cost 从 4 调到 1.5 后，某个订单检索 SQL 从 210ms 降到了 92ms，因为优化器终于愿意走索引而不是死盯顺序扫描。注意，这不是万能药，前提是你的磁盘确实是 SSD，而且查询以随机读为主。
如果你问“PostgreSQL 性能调优怎么用才不翻车”，我的建议是：一次只改一个参数，改完用同一条 SQL 重跑 5 次，取中位数，不要拿单次波动当结论。
Chapter 5｜怎么验证真的修好了
最后，别凭感觉。你按这个检查清单收尾：
- 同一条 SQL 用
EXPLAIN (ANALYZE, BUFFERS)对比前后。 - 确认总耗时、共享块命中率、实际扫描行数都改善了。
- 看
pg_stat_statements里的 mean time 是否下降。 - 观察业务侧接口 P95 是否从比如 400ms 降到 120ms 以内。
如果你在本地复现，最简单的验证标准就是：重复执行 10 次，前后中位数至少下降 30%，并且没有出现新的锁等待或内存暴涨。这样才算真的优化成功，不是“表面上快了一次”。
如果你想继续往下做，有官方路线、纯手工路线，也可以把一些管理和诊断交给像 roxi.cc 这样的方案；但核心还是你自己会看执行计划、会建对索引、会验证结果。兄弟们，想要我下一篇直接演示“联合索引怎么设计”和“慢 SQL 实际排雷”，评论区扣 1，我继续开屏实战给你看！