为何已创建索引的PostgreSQL数据库仍执行排序操作？

1. 为什么选择Parallel Bitmap Heap Scan而非索引扫描 #

当你的查询通过comp_id IN (...)匹配到大量数据（本次返回了295813行）时，PostgreSQL优化器会对比不同执行计划的成本：

• **索引扫描（Index Scan）**需要遍历索引中所有匹配comp_id的条目，再逐个通过索引定位到表中的物理行，这会产生大量随机IO，数据量越大，性能越差。
• Bitmap Heap Scan则先通过索引构建匹配行的位图（标记包含目标行的数据块），再按数据块顺序批量扫描表，将随机IO转为顺序IO，效率更高。加上并行执行（Parallel）后，多个worker进程可以同时处理不同数据块，进一步提升扫描速度。因此优化器判断这个计划的总成本更低，选择了它。

2. 为什么会出现排序操作 #

你的events_idx索引确实按comp_id维护了顺序，但Bitmap Heap Scan的返回结果是按表的物理存储顺序输出的，和索引的排序逻辑无关，所以结果本身是无序的：

• 如果你的查询包含ORDER BY子句（比如按comp_id或id排序），数据库必须对无序的扫描结果执行排序，以满足输出要求。
• 如果查询没有显式ORDER BY，执行计划中的排序是因为Gather Merge的并行策略：优化器认为让每个worker先对自己处理的子集排序，再合并成全局有序结果，比把所有数据集中到主节点后再排序的成本更低。不过要注意，PostgreSQL在无ORDER BY时不保证结果顺序，这个排序是优化器基于成本估算做出的选择，并非强制要求。

如何避免不必要的排序 #

如果你的查询需要按comp_id有序返回，可以尝试：

• 创建覆盖索引：

  CREATE INDEX events_idx_covering ON events_table (comp_id) INCLUDE (id);
  

  这样优化器可能选择Index Only Scan，直接从索引中读取有序的comp_id和id，无需回表，自然也不需要排序。
• 若确定优化器成本估算有误（比如数据分布特殊），可以临时用SET enable_bitmapscan = off;强制禁用位图扫描，但不推荐长期使用，优化器的成本估算通常更可靠。

内容的提问来源于stack exchange，提问作者Nutonion Floyiviod