インデックスの有用性を検証

NO IMAGE

.kawa table{
border-collapse: collapse;
}
.kawa th {
border: solid 1px #666666;
padding: 1em;
background-color: #FAFAD2;
color: #000000;
}
.kawa tr.head th{
background-color: #04E69B;
}
.kawa td {
border: solid 1px #666666;
color: #000000;
padding: 0.5em;
background-color: #FFFFFF;
}
.kawa h2{
background-color: #B0E0E6;
border: solid 1px #666666;
font-weight: bold;
padding: 0.2em;
color: #000000;
}


インデックスを使用すると体感で早くなったと感じることも多いと思います。
ですが今回は速度の向上を視覚化するため、
ORACLEの機能の一つでもある実行計画を使い、検証してみます。

また前提条件として、オプティマイザの実行計画を明示的に指示することが
可能な「ヒント」を使います。

今回使用するヒント

ヒント 意味
データへのアクセスパス FULL 全表走査
INDEX 索引スキャン
INDEX_COMBINE ビットマップ・アクセス・パスを使用

今回使用する「人事テーブル」表
　・以下の列にUniqueインデックス(B-Tree)
        ID
　・以下の列にnonUniqueインデックス(B-Tree)
       性別
　　   都道府県
　・10万件のデータを保持

WS000000.jpg

※使用アプリ：SI Objerct browser

目次

 カーディナリティの高いカラムで検証

IDカラムを使用します。
単一プライマリキーでもあるため、カーディナリティの高いカラムです。

では早速、実行計画を見てみましょう。
ヒントを使用し、フルスキャンするよう指示しています。
※緑文字がヒント

WS000001.jpg

上記の画像からは、以下の内容が読み取れます。
　①人事テーブルをフルスキャン
　②かかったコストが98

※このコストを小さくしていくことがチューニングの目標となります。

では次に、索引スキャンするよう指示します。

WS000003.jpg

上記の画像からは、以下の内容が読み取れます。
　①ID列の索引表をユニークスキャン
　②ユニークスキャンで得たROWIDを使用し人事テーブルにアクセス
　③かかったコストが2

約50倍早くなりました。

 カーディナリティの低いカラムで検証

性別カラムを使用します。
男女の2種類しか値が無く、カーディナリティの低いカラムです。

フルスキャンを指示

WS000004.jpg

コストが104です。

続いて索引スキャンを指示

WS000005.jpg

コストが５４４に跳ね上がりました。

フルスキャンに比べ、索引スキャンしたほうが約5倍も遅くなっています。

さらに続いて都道府県も索引スキャンを指示

WS000006.jpg

コストが344と性別に比べると多少減っていますが、フルスキャンにはかないません。

ビットマップインデックスで検証

都道府県カラムの索引をビットマップインデックスに変更してみます。

ビットマップインデックスはカーディナリティが低い場合に有効とされています。

WS000007.jpg

コストが93とフルスキャンの104に比べ多少早くなりました。

まとめ

・カーディナリティが高い場合は、B-Treeインデックスが非常に有効。
・カーディナリティが低い場合は、ビットマップインデックスが多少は有効。

ビットマップインデックスはちょっと期待はずれな結果でした。
実用化には程遠い感じです。(わたしの知識では)

有効な場面をさらに検証し、またご報告できればこれ幸いです。

がんばるか！