2章: where句
10.インデックスの結合
1) 問題の本質
- 複数列の条件があると 単一の B-tree マルチカラム索引 で全てを効率化できない場合がある（特に複数の独立した範囲条件があるとき）
- 事前にクエリパターンを予測できない（＝アドホック検索が多い）環境では、最適なマルチカラム索引を用意できない
2) データベースがインデックス結果をまとめる方法
1. インデックス結合（Index Merge / Bitmap AND/OR）
- 各列のインデックスを個別に走査し、結果（ROWID等）を合成して最終候補を作る
- 長所：クエリが事前に分からなくても複数インデックスで対処できる
- 短所：複数インデックス走査＋中間結果のマージで CPU・メモリ負荷が高い。OLTPではコストが高くなりがち
2. データウェアハウス流（ビットマップインデックス）
- 各列にビットマップインデックスを作り、簡単にビット演算で条件を合成できる
- 長所：複数条件の合成が非常に高速で、アドホック問い合わせに強い
- 短所：INSERT/UPDATE/DELETE の書き込みコストが極端に大きく、同時書き込みに弱い
➡ OLTPには不向き（主にDWH向け）
3) ハイブリッド手法（実行時ビットマップ化）
- 多くのDBは B-tree スキャン結果を 一時的にメモリ上のビットマップに変換して合成する機能を持つ（永続化しない）
- 長所：ビットマップの利点を得つつ、ビットマップ索引の書き込み問題は回避できる
- 短所：メモリとCPUを大量消費するため、オプティマイザの最後の手段的手法
4) 結論
- クエリパターンが事前に分かる → マルチカラム B-tree インデックス を優先
- アドホックで多次元の条件が頻出（DWH） → ビットマップインデックス が適切
- OLTPでアドホックな結合がたまに起きる → DBの インデックス結合 や 一時ビットマップ に頼るが、コストに注意
まとめ
B-tree は1次元（範囲1つ）に強い。複数条件の合成はコストがかかるため、用途（OLTP vs DWH）に応じてマルチカラム索引・ビットマップ・インデックス結合を使い分ける