PostgreSQL 位圖索引掃描實戰解析：從 EXPLAIN 看 Bitmap Heap/Index Scan 運作細節

位圖索引掃描 是 PostgreSQL 针對「中等選擇率」查詢的核心優化路徑。本文以實際 EXPLAIN ANALYZE 輸出為例，拆解 Bitmap Index Scan → Bitmap Heap Scan 的兩階段機制。

什麼是位圖索引掃描？

當查詢條件選擇率介於「全表掃描」與「索引掃描」之間（約 1%~15%），PostgreSQL 會：

1. Bitmap Index Scan：掃描索引，不直接取 tuple，而是建立一個位圖，每個 bit 對應一個 heap 頁面（或 tuple），標記「可能符合」的頁面。
2. Bitmap Heap Scan：依位圖順序讀取 heap 頁面，並對每個 tuple 重新檢查條件（Recheck Cond），過濾假陽性。

實戰 EXPLAIN ANALYZE 解讀

QUERY PLAN
--------------------------------------------------------------------------------------------------
Bitmap Heap Scan on bitmap_test (cost=2023.16..4157.75 rows=99967 width=4)
  (actual time=24.373..41.054 rows=100000 loops=1)
  Recheck Cond: (is_visible = 'yes'::bpchar)
  -> Bitmap Index Scan on idx_bitmap_is_visible (cost=0.00..1998.17 rows=99967 width=0)
       (actual time=24.252..24.252 rows=100000 loops=1)
       Index Cond: (is_visible = 'yes'::bpchar)
Total runtime: 47.175 ms

關鍵欄位逐行拆解

位圖索引 vs B-Tree 索引掃描：選擇邏輯

優化建議

• 維持統計資料新鮮：ANALYZE 或啟用 autovacuum，否則規劃器誤判選擇率導致走錯路徑
• work_mem 過小會導致位圖「失真」退化為 Bitmap Index Scan -> Heap Scan (lossy)，需適度調大（如 64MB~256MB）
• 多欄位查詢考慮多欄索引或位圖 AND/OR 合併多個單欄索引（規劃器自動決定）
• 唯讀/靜態表可用 BRIN 索引替代，空間極小

總結： 位圖掃描是 PostgreSQL 「中間地帶」的利器，關鍵在於 work_mem 足夠、統計資料準確、條件選擇率落在最佳區間。