bitmap索引を使用する際の適切なカーディナリティ数について

Question

下記マニュアルを確認するとbitmap索引はカーディナリティ数が少ない列に対して設定するのが効果的と記載があります。
確かに性別の「男」、「女」やステータス値がある列に対してbitmap索引を作成されている例を良く見ました。
具体的な目安としてどのくらいの個別値のある場合にb-tree索引ではなくbitmap索引を使用した方が良いのでしょうか。

https://docs.oracle.com/cd/E16338_01/server.112/b56309/indexes.htm

ビットマップ索引は、表の行数に対する個別値の数の比率が小さい列に対して最も効果的です。

以上、よろしくお願い致します。

Answer 1

bitmap索引はON句WHERE句の条件によってはアクセスが早いですが、インデックスを更新する負荷がおおきいため、頻繁に更新されるテーブルには向きません。
ビットマップインデックスについて調べた
EXPLAIN PLAN で実行計画を確認したり、処理時間を実測したりして、適切な索引を選択します。

Comments

[statshu]

参照系テーブルの索引を想定しています。
チューニング時に実行計画を見比べて最適な索引を…というのは理解できます。
ただ、索引設計時に実行計画を見つつ最適な索引を付与というのは方法として適さないと感じています。
したがって、具体的なカーディナリティの目安値や索引付与方針例を知りたかったのです

[Orlofsky]

いちおうON句WHERE句で記述される列が索引の対象になります。索引が多くなると索引を書き換える負荷も多くなります。
パフォーマンスの改善方法は索引の設定だけではありません。きちんと統計情報を取得しているか？対象データが多ければ PARALLELヒント、USE_HASHヒントなどを使ったり、より効率的にアクセスできるようテーブル構造を変えたり、いろいろな方法も考えます。
http://www.oracle.com/technetwork/jp/database/articles/tsushima/index.html
辺りが参考になるでしょう。

許容できるレスポンス時間はそのシステムによって違います。お金はかかりますが、パフォーマンス・チューニングの熟練者に改善を依頼することも必要かもしれません。
Oracle側でこれ以上改善できない場合は、本当にクリティカルなシステムならハードウェアにお金をかけることも考えます。

[statshu]

パフォーマンス改善方法を質問していたわけではありません。
言葉足らずかもしれませんが、bitmap索引を使用する場合の具体的なカーディナリティの目安値や索引付与方針例を知りたかったのです。
ともかくありがとうございました。