如何优化PostgreSQL查询中的Bitmap Heap Scan？附执行计划与索引说明

针对你遇到的PostgreSQL查询里Bitmap Heap Scan开销过高的问题，结合你已经在orders.account_id和orders.completion_date字段建了单字段索引的情况，我整理了几个实际项目里常用的优化思路，你可以挨个试试：

• 优先考虑创建联合索引
  如果你的查询同时用到了account_id和completion_date作为过滤条件，单独的单字段索引其实没法让数据库一步到位定位到目标数据。不如把这两个字段做成联合索引：

  CREATE INDEX idx_orders_account_completion ON orders(account_id, completion_date);
  

  这样数据库通过联合索引就能一次性筛选出符合两个条件的记录，后续Bitmap Heap Scan需要扫描的行数会大幅减少，开销自然降下来。

• 尝试转为索引覆盖扫描（Index-Only Scan）
  看看你的查询是否只需要返回orders表中的部分字段。如果查询的所有字段（包括过滤条件和返回结果）都能被索引覆盖，PostgreSQL可以直接从索引里拿数据，完全跳过Bitmap Heap Scan。比如你的查询是SELECT id, amount FROM orders WHERE account_id = ? AND completion_date BETWEEN ? AND ?，就可以把需要返回的字段加入索引：

  CREATE INDEX idx_orders_account_completion_include ON orders(account_id, completion_date) INCLUDE (id, amount);
  

• 更新表的统计信息
  有时候数据库的统计信息过时，会导致优化器判断失误，选不到最优的执行计划。你可以手动更新一下orders表的统计信息：

  ANALYZE orders;
  

  让优化器能更准确地估算过滤后的行数，从而调整Bitmap Heap Scan的执行策略。

• 清理表的碎片化
  如果orders表经常做更新、删除操作，会导致表数据碎片化严重，Bitmap Heap Scan读取数据时需要频繁跳转磁盘块，开销自然上去。可以用这条命令清理碎片并整理数据：

  VACUUM ANALYZE orders;
  

  整理后的数据会更紧凑，Heap Scan的读取效率会提升不少。

• 临时调整work_mem参数应急
  Bitmap Heap Scan依赖于bitmap的构建，如果work_mem设置太小，bitmap可能会溢出到磁盘，导致性能骤降。你可以临时给当前会话调大这个参数试试：

  SET work_mem = '64MB';
  

  注意这只是短期应急方案，长期要根据服务器内存总量合理配置全局参数，避免影响其他查询。

最后补充一点：如果你的查询返回的结果集特别大（比如超过表总行数的20%-30%），那Bitmap Heap Scan可能本身就是最优选择——因为此时全表扫描的开销反而更低，这种情况下优化空间就不大了，建议评估能不能缩小查询的过滤范围。

内容的提问来源于stack exchange，提问作者Mikhail Nikalyukin