Postgres 索引：Web 应用里最常见的几张慢查询

Web 应用的慢，很多时候不是 Node「不够快」，而是 SQL 在扫表。索引不是越多越好，但该有的复合索引缺了会非常痛。

先看执行计划

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, title, published_at
FROM posts
WHERE category = 'frontend'
ORDER BY published_at DESC
LIMIT 20;

关注：是否 Seq Scan、是否 Sort 很大、Buffers 是否夸张。

复合索引的顺序

常见列表：WHERE category = ? ORDER BY published_at DESC。

CREATE INDEX posts_category_published_at_idx
  ON posts (category, published_at DESC);

把等值条件放前面，排序字段接在后面，往往比两个单列索引更贴查询。

外键与存在性

comments.post_id 上若没有索引，删文章或按文章拉评论时容易拖垮。外键列默认不会自动具备你期望的所有查询索引——要按访问路径补。

不要索引一切

• 低基数列（如布尔 draft）单独索引收益有限，常要和更有选择性的列组成复合索引。
• 频繁更新的宽索引会拖慢写入。
• 先有慢查询证据，再加索引；加完用同样的 EXPLAIN 验收。

小结

索引设计跟随真实查询形状。把 EXPLAIN ANALYZE 放进性能排查的第一步，比先升级机器更便宜。