新インデックスの検証　その７

＜新インデックスの検証　その７＞　ペンネーム　モンキーターン

今回も、引き続き Functionインデックスの検証を行なう。

検証スタート！！！

Functionインデックスはコストベース・オプティマイザで使用されるため、
統計情報を取得しておく必要がある。

ユーザ scottで

SQL> analyze table emp_200man2 estimate statistics ;

表が分析されました。

SQL> analyze table emp_200man2 estimate statistics
                                   for all indexed columns ;

表が分析されました。

Functionインデックスを使用した検索を行なう場合、通常の統計情報だけでは
式を含む条件の選択を正確に見積もれない場合があります。式のヒストグラム
を取得することで、オプティマイザは正確な選択を見積もることができるよう
になります。

これで、Functionインデックスを使用した検索が可能となった。

SQL> select empno, ename from emp_200man2 where empno*(sal-100) < 1000 ;

＜Functionインデックスなし＞
検索時間 = 22.06秒

実行計画
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'EMP_200MAN2'

＜Functionインデックスあり＞
検索時間 = 00.04秒

実行計画
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EMP_200MAN2'
   2    1     INDEX (RANGE SCAN) OF 'FUNC_IDX' (NON-UNIQUE)

＜DML処理( insert )の検証＞
インデックスなしの場合
DML処理時間 = 2分09.02秒

Normalインデックスの場合
DML処理時間 = 4分38.09秒

Functionインデックスの場合
DML処理時間 = 8分09.01秒

上の結果より
Functionインデックスでは、式や関数の結果が計算されて、インデックスに格
納されているので、式や関数の計算をスキップすることが可能である。これに
より式や関数が複雑で処理負荷が高い場合は、検索性能を大幅に向上されるこ
とができると予想される。しかし、FunctionインデックスはDML処理が大幅に
増加すると予想される。

Funcitonインデックスの機能を利用すれば、大文字/小文字を区別せずにソート
されたインデックス(UPPER/LOWER関数使用)やNLS言語順にソートされたインデ
ックス(NLSSORT関数使用)を作成することも可能である。

ゆえに、Functionインデックスのメリット・デメリットを理解した上で、使っ
ていただきたい。

前回お伝えしたキー圧縮やIndex Skip ScanもFunctionインデックスはサポー
トしている。
以下はサポートされている機能である。
・複合インデックス
・インデックスのパーティション化
・パラレルでのインデックス作成
・パラレルインデックス走査
・高速全インデックス走査（パラレル）
・一意インデックス
・ビットマップインデックス
・キー圧縮
・Index Skip Scan

今回の検証で、Functionインデックスの性能を理解していただいたと思う。
次回は、bitmap join インデックス( Oracle9iから )の検証を行なう。

次回もお楽しみに・・・つづく

以上今年の忘年会は、何やろっかなぁー。茅ヶ崎にて

新インデックスの検証 その７