在PostgreSQL数据库中，当单表数据量增长到千万级别时，一条看似简单的查询可能从毫秒级退化到十几秒。很多性能问题的根源并不在于SQL写法糟糕，而是复合索引的列顺序与设计预期相悖。B树索引从根节点到叶子节点按第一列、第二列、第三列依次排序，这种结构决定了查询必须从最左列开始匹配，一旦跳过前列，索引便失去导航能力。
最左前缀原则与列顺序的底层逻辑
PostgreSQL默认的B树索引要求查询条件符合最左前缀才能完整利用索引。假设我们建立索引 idx_user (city, age, created_at)，索引在物理上先按 city 排序，相同 city 内再按 age 排序，以此类推。当执行 WHERE city = '北京' AND age > 20 时，数据库能先通过 city 快速定位到北京的分支，再在分支内做 age 范围过滤。但如果只写 WHERE age > 20，由于缺失第一列，索引无法知道从哪个城市入口进入，只能放弃索引选择全表扫描。
列顺序还直接影响索引的过滤效率。把基数大、等值查询频繁的列放在左侧，可以让每一次比较都砍掉大量数据块。反之，若把低区分度列（例如性别，只有男女）放在最左，即使命中索引，仍然要扫描几乎一半的叶子节点，优化器可能认为不如直接全表顺序读更划算。我们可以通过系统视图 pg_stats 查看每个字段的 n_distinct 来辅助判断选择性。
下面用一段SQL展示如何观察统计信息，从而决定哪列适合做索引引导列：
SELECT attname, n_distinct, most_common_vals
FROM pg_stats
WHERE tablename = 'user_log'
AND attname IN ('city', 'age', 'status');
等值查询与范围查询的摆放策略
在慢查询优化实践中，一个被反复验证的经验是：等值条件列放左边，范围条件列放右边。原因在于B树对等值匹配可以精确到唯一路径，而范围匹配只能在某个区间内向后顺序遍历。如果范围列在左，等值列在右，那么索引只能利用范围部分，后面的等值条件无法在索引内继续收敛。
考虑订单表场景，常见查询为 WHERE user_id = 123 AND create_time > '2023-01-01'。若建立 (create_time, user_id) 的索引，由于 create_time 是范围，索引先圈出一段时间片，再在片内找 user_id，效率一般。改为 (user_id, create_time) 后，先精准定位用户的所有记录，再在其中做时间过滤，逻辑读显著下降。我们可以用 EXPLAIN (ANALYZE, BUFFERS) 对比两者差异。
以下代码演示了两种索引顺序下的执行计划观察方式：
-- 建立两种顺序的索引用于对比 CREATE INDEX idx_a ON orders (create_time, user_id); CREATE INDEX idx_b ON orders (user_id, create_time); EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE user_id = 123 AND create_time > '2023-01-01';
从输出中重点看 shared read 和 rows removed by filter。通常 idx_b 的缓冲区读取会更少，因为索引本身已经按用户聚簇了时间，不需要回表过滤大量无关用户行。
排序、连接与冗余索引的协同考量
复合索引不仅能加速WHERE，还可以消除ORDER BY带来的额外排序开销。当索引列顺序与排序字段一致且方向相同，PostgreSQL可直接按索引顺序返回结果，避免内存中的 Sort 节点。例如 INDEX (dept_id, salary DESC) 正好覆盖 WHERE dept_id = 5 ORDER BY salary DESC，执行计划会出现 Index Scan 而非 Sort。但如果查询是 ORDER BY salary ASC，方向不匹配仍可能触发排序。
在多表连接场景，索引列顺序还要兼顾连接键。若查询频繁以 a.customer_id = b.id 关联，且 a 表常带 region 过滤，那么 (region, customer_id) 的复合索引可同时服务过滤与连接，让嵌套循环的外表 lookup 更高效。不过要注意，每增加一个复合索引都会拖慢INSERT和UPDATE，因为写操作需同步维护所有索引树。
冗余索引是另一个隐形杀手。有的团队既建了 (city) 单列索引，又建了 (city, age) 复合索引，其实前者已被后者最左前缀覆盖，可以删掉单列索引减轻写入负担。定期用 pg_indexes 结合 pg_stat_user_indexes 的扫描次数，清理长期零命中的复合索引，是慢查询治理的常态化动作。
SELECT indexrelname, idx_scan, idx_tup_read FROM pg_stat_user_indexes WHERE relname = 'user_log' ORDER BY idx_scan ASC;
通过上述视图找出扫描次数为0的索引，确认业务无特殊报表依赖后，使用 DROP INDEX CONCURRENTLY 安全删除，避免锁表影响线上服务。
PostgreSQL复合索引慢查询优化修改时间：2026-08-13 11:27:37