新インデックスの検証 その4
<新インデックスの検証 その4> ペンネーム モンキーターン
今回は、再度[ 検索時間 ]についての検証を行なう。
キー圧縮インデックス・Index Skip Scanの検索は、[ 検索時間 ]に変化は起こ
るのであろうか?
検証スタート!!!
今回の検証目的は、
「 キー圧縮インデックスのIndex Skip Scanの[ 検索時間 ]とNormalインデックスの差 」
を検証する。
検証用テーブル( emp_200man )を作成する。
create table emp_200man( EMPNO NUMBER , ENAME VARCHAR2(10) , JOB VARCHAR2(9) , MGR NUMBER(4) , HIREDATE DATE , SAL NUMBER(7,2) , COMM NUMBER(7,2) , DEPTNO NUMBER(2) ) ;
データ件数は、200万件である。
このテーブルのカラムEMPNOは、一意な値を挿入する。
次に以下のインデックスを作成する。
1. create index normal_idx on emp_200man( empno ) ; 作成時間 = 1分28.03秒 領域サイズ = 37.0MB 2. create index normal2_idx on emp_200man( ename, empno ) ; 作成時間 = 2分24.04秒 領域サイズ = 50.0MB 3. create index comp_idx on emp_200man( ename, empno ) compress 1 ; 作成時間 = 2分20.04秒 サイズ = 37.0MB
ちなみにカラムENAMEは、個別データ数が14件しかないデータである。
<今回使用する検索SQL文>
a. select * from emp_200man where empno = 1000000 ;
Table Full Scanの検索時間 検索時間 = 18.04秒 Normalインデックス( インデックス1 )の検索時間 検索時間 = 0.02秒 Normal複合インデックス( インデックス2 )のIndex Skip Scan検索時間 検索時間 = 0.04秒 キー圧縮複合インデックス( インデックス3 )のIndex Skip Scan検索時間 検索時間 = 0.04秒
上の結果より
Index Skip Scanの検索は、Normalインデックス検索とさほど変わらず
且つキー圧縮のIndex Skip Scan検索もNormalインデックスやNormal複合イン
デックスのIndex Skip Scan検索とさほど変わらなかった。
また、複合インデックスのカラム数を増やした場合や複合インデックス作成時
にEMPNOカラムの位置を変えてみたがIndex Skip Scan検索時間にほとんど影響
が見られなかった。
ここで、注意すべき内容を示す。
Index Skip Scanをオプティマイザが選択するには
1. analyze table xxxx estimate statistics か compute statisticsの実行 が必要である。 2. 複合インデックスの作成時のカラム構成で、Prefixカラム( 検証Objectで 言うENAMEカラム )の個別データ数が Index Skip Scanをオプティマイザが 選択する大きな要素になっている。
今回の検証結果で、
Index Skip Scan機能により、Oracle8i以前は複数のインデックスが必要だった
ものを1つの複合インデックスで作成でき、重複データの多いカラムをPrefixカ
ラムで作成しキー圧縮をすることにより、[ 検索時間 ]をほんの少し犠牲する
ことにより、[ 作成時間 ][ 領域サイズ ]は大幅に削減されることができる。
インデックスの数も減るのでメンテナンス・オペレーションの軽減も可能であ
る。
これで、DML処理が向上する結果が得られれば・・・
次回は、キー圧縮インデックスのDML処理負荷の検証を行なう。
次回もお楽しみに・・・つづく
以上 はっはっハックション (#`ε´#) 風邪引いてしまった 茅ヶ崎にて