位图扫描：被误解最多的PostgreSQL“Join”技术
先说一个很多人在理解上容易跑偏的点：PostgreSQL在面对JOIN查询时，并不会“优先考虑”位图扫描。因为，位图扫描（Bitmap Index Scan）压根儿就不是一种JOIN算法——准确说，它只是单表扫描的一种方式，和Nested Loop、Hash Join这些连接算法处于完全不同的层级。它只在JOIN过程中某张参与表的WHERE条件过滤阶段发挥作用，决定它的，是这张表自身的过滤条件、索引结构和统计信息。
那到底什么时候会在JOIN执行计划里看到位图扫描？
位图扫描出现在JOIN执行计划中某张表的扫描节点时，通常满足几个前提条件：
- 这张表的JOIN条件加上其他WHERE条件，能同时命中多个独立的单列索引。比如
ON t1.id = t2.t1_id WHERE t2.status = 'active' AND t2.created_at > '2025-01-01'，而status和created_at各自又有单列索引。 - 查询返回的行数处于中等水平——几千到几十万条。这个量级比较尴尬：不够少，走
Index Scan回表不划算；又不够多，直接Seq Scan全表扫反而更省事。 work_mem得够用，默认4MB。如果装不下位图的内存结构，优化器可能会降级为Index Scan，甚至退回到顺序扫描。- 最后也是最重要的，优化器算完账之后，认为位图扫描这条路的总代价最低。
位图扫描和JOIN算法：互不干扰的两个决策层级
所以，你在实际执行计划中完全可能看到这样的混合组合：
- Hash Join 内部，右表用
Bitmap Heap Scan加载数据——常见于大表JOIN小表，且右表有复杂的过滤条件。位图扫描先把符合条件的行标记出来，再一次性回表取数据，交给Hash Join去配对。 - Nested Loop 中，内表虽然通常走精确的
Index Scan来快速定位，但如果内表还有额外的WHERE条件，也有小概率触发Bitmap Index Scan——不过这种情况确实少见，毕竟Nested Loop的优势就在于精准的单点查找。 - Merge Join 基本不会和位图扫描沾边。它要求两边数据有序，通常依赖
Index Scan或显式的Sort，而位图扫描不保证输出顺序。
总结成一句话就是：Bitmap Index Scan 解决的是“怎么从一张表里把数据捞出来”的问题，而 Hash Join 解决的是“捞出来的两张表怎么配对”的问题。 二者属于不同维度的决策，不能混为一谈。
为什么这么多人误以为它“优先”？
原因很简单——在实际生产中，你经常在EXPLAIN ANALYZE的输出里看到类似这样的结构：
Hash Join (cost=123.45..678.90 rows=5000 width=128) Hash Cond: (t2.t1_id = t1.id) -> Bitmap Heap Scan on t2 (cost=10.20..520.30 rows=5000 width=64) Recheck Cond: (status = 'active'::text) -> Bitmap Index Scan on idx_t2_status (cost=0.00..10.00 rows=5000 width=0) Index Cond: (status = 'active'::text) -> Seq Scan on t1 (cost=0.00..100.00 rows=10000 width=64)
这里 t2 表用了位图扫描，是因为它自身的过滤条件 status = 'active' 刚好适合用位图来组织。这跟JOIN策略选什么完全无关。不信你把过滤条件换成主键等值 t2.id = 123，优化器大概率秒改用Index Scan；如果去掉所有WHERE条件，它就老实走Seq Scan全表扫了。
调优时真正该盯紧的点是什么？
别盯着“为什么用了位图”不放，真正需要关注的是下面这几个地方：
- 位图扫描的
rows估算是否严重偏离实际。在EXPLAIN ANALYZE里对比一下“planned rows”和“actual rows”，偏差过大会直接误导JOIN顺序的选择，让整个计划跑偏。 Bitmap Heap Scan后面有没有大量Recheck Cond。这意味着位图精度不够，需要二次过滤。一旦出现，IO和CPU开销都会明显上升。- 是不是因为缺少复合索引，被迫用多个单列索引拼出位图？ 比如
WHERE a = ? AND b > ?这种场景，建一个INDEX ON t(a, b)复合索引，往往比依赖位图高效得多。 work_mem是否被多个并发查询挤占，导致本该用位图的场景被迫降级。这是生产环境里最容易忽略的性能瓶颈。
说到底，位图扫描是优化器在特定数据分布下做出的务实妥协，不是万能银弹。它之所以给人“存在感强”的印象，恰恰是因为它总出现在那些“难搞”的中等规模过滤场景里——而这，恰好是业务SQL最常卡住的地方。
