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

<新インデックスの検証 その7> ペンネーム モンキーターン

今回も、引き続き 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から )の検証を行なう。

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

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