Bitmap 索引以位圖結構實現低基數欄位的高效查詢，但其獨特的鎖定機制與儲存特性決定了**並非萬能**。本文系統梳理 Bitmap 索引的核心特性、三大黃金適用場景、硬性限制，並給出混合索引部署策略。
一、 核心特性回顧
- 建立機制：全表掃描 → 對每個唯一值建立位圖 → 位元映射 ROWID
- 邏輯運算：多條件 AND/OR 直接對位圖做位運算，再計算結果位圖中 1 的個數
- NULL 支援：將 NULL 視為獨特值建立位圖，
IS NULL 可走索引
二、 三大黃金適用場景
| # | 場景 | 典型欄位 | 效能增益 |
|---|
| 1 | 基數極低 (< 100) + 高頻篩選 | 性別、狀態碼、區域代碼、是否標記 | 位圖極小，位運算替代大量回表 |
| 2 | 多條件 AND/OR 組合查詢 | WHERE status='A' AND region='N' OR type='VIP' | 單次位運算完成複合篩選 |
| 3 | 需高效查詢 NULL 值 | 身分證號、護照號、選填屬性 | 唯一支援 NULL 索引的類型 |
三、 硬性限制與反模式
- 高基數欄位禁用：員工編號、姓名、身分證號 → 位圖數量龐大，儲存/維護成本指數級上升
- 高併發 DML 禁用：單列 UPDATE 會鎖定該值對應的**所有列**，導致嚴重併發阻塞
- 不支援函數索引：
UPPER(name)、SUBSTR(id,1,6) 必須用 Function-based B-tree
- 不支援索引區分度統計：CBO 對 Bitmap 選擇率估算較粗略，需配合直方圖
四、 索引類型選型決策樹
IF 基數 < 100 AND (多 AND/OR 條件 OR 需查 NULL) AND 低併發寫入
THEN Bitmap 索引
ELSIF 欄位含函數運算
THEN Function-based B-tree
ELSIF 高基數 OR 高併發寫入 OR 主鍵/唯一約束
THEN B-tree (Normal/Reverse Key)
ELSE
THEN 評估是否需要索引（小表可能全掃更快）
五、 混合部署實戰模式
同一張表可同時擁有多種索引，服務不同查詢路徑：
| 欄位 | 索引類型 | 服務查詢 |
|---|
| emp_id (PK) | B-tree (Unique) | 單筆精確查詢、JOIN |
| dept_id | B-tree (Normal) | 部門篩選、JOIN、範圍查詢 |
| gender | Bitmap | 性別統計、複合條件 |
| marital_status | Bitmap | 婚姻狀態統計、AND 組合 |
| id_card | Function-based B-tree (NVL) | 查詢無身分證員工 |
| created_date | B-tree (Local Partitioned) | 時間範圍查詢、分區裁剪 |
六、 維護最佳實務
- 定期監控
V$SEGMENT_STATISTICS 中 logical reads、buffer busy waits 判斷索引效益
- Bitmap 索引重建：
ALTER INDEX bmp_idx REBUILD;（離線）或 COALESCE（線上）
- 大批次載入前
DROP Bitmap 索引，載入後重建，避免逐筆維護開銷
- 配合
DBMS_STATS.GATHER_TABLE_STATS(..., METHOD_OPT=>'FOR ALL COLUMNS SIZE AUTO') 收集直方圖提升 CBO 估算
七、 升級遷移提醒
- 12c 起支援
BITMAP INDEX 於 INMEMORY 表，查詢可走 In-Memory 向量化
- 19c 強化
BITMAP INDEX 統計資訊自動收集
- 遷移至 Exadata/Autonomous DB 時，評估
STORAGE INDEX 與 HYBRID COLUMN COMPRESSION 替代傳統 Bitmap
Bitmap 索引是低基數、複合條件、NULL 查詢的**利器**，但也是高併發寫入的**毒藥**。掌握其邊界，構建「B-tree 主導、Bitmap 補強、Function-based 專項」的混合索引矩陣，才是資料庫架構師的核心功力。
- 上一篇文章： Oracle 索引選型實戰：為何低基數欄位必須用 Bitmap 而非 B-tree
- 下一篇文章： Oracle 表欄位修改全操作指南：增、改、刪、重命名與註解管理
Copyright ©
程式碼之家 All Rights Reserved
