PostgreSQL中为何排序操作未使用指定的联合索引？

你创建了(client_id desc, created_at desc)的联合索引，但执行SELECT * FROM orders WHERE client_id = 7 ORDER BY created_at desc时，执行计划显示用了quicksort而非索引排序，核心原因是PostgreSQL优化器基于成本估算选择了更高效的执行路径，具体拆解如下：

1. 索引未覆盖所有查询字段，回表成本不可忽视 #

你的查询是SELECT *，需要返回id、client_id、total、created_at所有列。而你创建的联合索引仅包含client_id、created_at以及隐含的主键id（PostgreSQL非主键索引会自动包含主键）。如果选择走索引扫描（Index Scan），需要先从索引中找到匹配client_id=7的条目，再根据主键去堆表中读取total列，这个回表过程会产生大量随机IO——尤其是当匹配的行分布在不同堆页面时，随机IO的代价很高。

2. 小数据量下内存排序的成本远低于索引扫描+回表 #

从执行计划可以看到，实际匹配的行数是1046行，这个数据量非常小。PostgreSQL使用内存quicksort仅消耗130kB内存，几乎没有性能开销。优化器计算后认为：先通过**位图索引扫描（Bitmap Index Scan）收集所有匹配行的位置，再通过位图堆扫描（Bitmap Heap Scan）**批量读取堆页面（减少随机IO），最后做内存排序的总成本，比按索引顺序逐个回表的成本更低。

3. 位图扫描的批量读取优势 #

执行计划中的Bitmap Heap Scan会先把所有匹配行的位置整合到位图中，然后按页面顺序扫描堆表，这样能最大化利用顺序IO，减少磁盘访问次数。虽然最后需要排序，但排序的开销远低于随机回表的开销，所以优化器选择了这个路径。

如何让查询使用索引排序？ #

如果确实想让查询利用索引排序，可以尝试以下两种方式：

• 修改为索引覆盖查询：如果业务允许只查询索引包含的字段（id、client_id、created_at），执行SELECT id, client_id, created_at FROM orders WHERE client_id = 7 ORDER BY created_at desc，此时索引已覆盖所有查询字段，优化器会直接走Index Scan且不需要排序。
• 扩展索引为覆盖索引：如果必须查询total列，可以在PostgreSQL 11及以上版本使用INCLUDE子句扩展索引：

CREATE INDEX ON orders (client_id desc, created_at desc) INCLUDE (total);

此时索引包含了所有查询字段，执行SELECT *时会直接走Index Scan，利用索引的顺序避免排序。

• 临时禁用位图扫描（仅用于测试）：执行SET enable_bitmapscan = off;后再执行查询，优化器会选择Index Scan并利用索引排序，但不建议在生产环境长期使用，这会强制优化器放弃更优的执行路径。

内容的提问来源于stack exchange，提问作者Guy Fawkes