索引の使い分けでパフォーマンスを向上できるケース：Oracle SQLチューニング講座（9）（2/4 ページ）

本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。（編集局）

[倉田寛正，株式会社アゲハ]

ビットマップ索引の使用

　ビットマップ索引では、索引列の値と各レコードがその値に該当するか否かを表すビットマップが保持されており、検索処理ではビットの有無で条件に該当するか否かが判定されます。カーディナリティの低い複数の列をWHERE条件に指定している場合など、各列にビットマップ索引を作成しておくことで、ビット演算による高速な検索を行うことが可能になります。また、第7回「索引を作成したのにパフォーマンスが悪いケース」の索引を使用できないケースで説明したようにNULL値の検索も可能です。

　ビットマップ索引では、B*Tree索引のように各レコードのROWIDを保持する必要がないため、索引のサイズが小さくて済みます。特にレコード件数が多い表の、カーディナリティが低い列に対して作成した場合に顕著となります。

　図4は、10、20、30、40の4つの値が格納されている列にビットマップ索引を作成した場合のイメージ図になります。図から分かるように、ビットマップ索引では表のレコードをいくつかのグループに分類して管理しており、グループごとにビットマップセグメントが割り当てられています。ビットマップ索引を使用する場合、更新処理実行時のロック単位がビットマップセグメント単位となる点に注意する必要があります。

　このため、複数の更新処理が同時に実行されるOLTP系のシステムよりも、データウェアハウスやBI系の参照処理が中心となるシステムで利用するようにしてください。

　図4　ビットマップ索引のデータ格納イメージ（クリックで拡大します）

　図5は、2種類のデータ（各50万件）を持つ列に対して、B*Tree索引とビットマップ索引を作成したときの索引サイズになります。

図5　B*Tree索引とビットマップ索引のサイズの比較

　図5の結果より、ビットマップ索引にすることで索引サイズが非常にコンパクトになったことが確認できます。大規模表に対して複数の索引を作成する場合などは、リソース面で大きなメリットを得ることができます。

　また、下記の図6、図7では、索引作成列のカーディナリティが高い（ユニーク）場合と、カーディナリティが低い場合の検索時間、索引オブジェクトサイズについて、まとめています。

図6　ユニークデータが格納されている場合

図7　カーディナリティ5のデータが格納されている場合

　図6と図7の結果から、使用領域、処理時間の観点では、カーディナリティが高い列に対してはB*Tree索引が最適であり、カーディナリティの低い列に対してはビットマップ索引が最適であることが確認できます。