PostgreSQL在执行SQL JOIN时为什么会优先考虑位图扫描

PostgreSQL中位图扫描不是JOIN算法，而是单表扫描方式，仅在某张表的WHERE过滤阶段启用，取决于其索引、统计信息和条件选择性；它与Nested Loop、Hash Join等连接算法正交独立。

PostgreSQL 在执行 JOIN 时**不会“优先考虑”位图扫描**——位图扫描（Bitmap Index Scan）根本不是 JOIN 算法，而是**单表扫描方式之一**。它只发生在 JOIN 的某一张参与表（通常是内表或驱动表）的 WHERE 条件过滤阶段，和 JOIN 本身无关。真正决定 JOIN 行为的是连接算法（Nested Loop、Hash Join、Merge Join），而是否对某张表启用 Bitmap Index Scan，取决于这张表自身的过滤条件、索引结构和统计信息。

什么时候会在 JOIN 中看到 Bitmap Index Scan？

它只出现在 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 或退化为顺序扫描）
• 优化器估算出位图扫描的总代价（索引扫描 + 位图构建 + 堆扫描）低于其他路径

Bitmap Index Scan 和 JOIN 算法是正交的

你完全可能看到这样的组合：

• Hash Join 内部，右表用 Bitmap Heap Scan（即位图扫描回表）加载数据 → 常见于大表 JOIN 小表，且右表有复合过滤条件
• Nested Loop 中，内表每次被驱动时走 Index Scan，但若内表加了额外 WHERE 条件，也可能触发 Bitmap Index Scan（不过更少见，因为 NLJ 通常期望快速单点定位）
• 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 的扫描用了位图，只是因为它自身过滤条件适合，并非 JOIN 策略偏好它。如果把 t2.status = 'active' 换成 t2.id = 123（主键等值），优化器大概率改用 Index Scan；如果去掉所有 WHERE，就变成 Seq Scan。

调优时真正该盯住的点

别盯着“为什么用了位图”，而要看：

• 位图扫描的 rows 估算是否严重偏离实际（EXPLAIN ANALYZE 中看 actual rows vs planned rows），偏差大会误导 JOIN 顺序选择
• Bitmap Heap Scan 后面有没有大量 Recheck Cond —— 这说明位图精度不足，需二次过滤，IO 和 CPU 开销都会上升
• 是否因缺少复合索引，被迫用多个单列索引拼出位图？比如 WHERE a = ? AND b > ?，建 INDEX ON t(a, b) 往往比依赖位图更高效
• work_mem 是否被多个并发查询挤占，导致本该用位图的场景被迫降级

位图扫描本身是优化器在特定数据分布下的务实妥协，不是银弹。它的存在感强，是因为它常出现在“难搞”的中等规模过滤场景里——而这恰恰是业务 SQL 最常卡住的地方。