索引（インデックス）の断片化の確認方法と対処方法

項目を追加・削除すると、データオブジェクトだけでなく関連する索引（インデックス）オブジェクトも更新されます。索引（インデックス）が追加・削除されるとオブジェクト内にすき間が生まれます。これが断片化です。断片化が発生するとパフォーマンスに影響を与えます。その索引（インデックス）の断片化の確認方法と断片化を解消する対処方法について解説します

（断片化のイメージ図）

索引（インデックス）の断片化の確認方法

B-Tree 索引（インデックス）は、B-Tree のレベル数（ルート・ブロックからリーフ・ブロックまでの階層）が高くなるとアクセス効率が低下します

データの削除が多く行われるとすき間ができブロックの使用効率が低下して B-Tree のレベル数が高くなります

その場合は索引（インデックス）を再構築（REBUILD）する必要があります

索引（インデックス）のアクセス効率が悪いかは、以下のように INDEX_STATS ビューの HEIGHT（Bツリーの高さ）とDEL_LF_ROW/LF_ROWS（削除されたエントリーの割合）を確認します

 

 

 

 

 

◆索引（インデックス）断片化の確認ポイント

HEIGHT が4以上で DEL_LF_ROW/LF_ROWS が0.2を超える場合は効率が悪い可能性があります

この場合、索引（インデックス）の再構築（REBUILD）を行うことを検討して下さい

 

◆断片化の対処方法

索引（インデックス）の再作成は、ALTER INDEXコマンドに、REBUILD句を使用します

REBUILD句を使用した再作成は、インデックスの空きブロック埋めて、インデックスを作り直します

また、DROP INDEXコマンドで削除した後で、CREATE INDEXで再作成する方が効率的な場合もあります

 

それでも索引（インデックス）のパフォーマンスが改善しない場合は、索引（インデックス）が使われていない場合があります

 

◆索引（インデックス）を過信しない

一般的にB-Treeインデックスが有効に動作するのは、取得するデータの量が表全体の5%～15%以下の場合です

一概には言えませんが、表全体の15％以上のデータを取得する場合や、検索する表の容量が小さい場合は、

全表走査(表のすべての行を読み込んでWHERE条件を判定)した方が高速になりますので、索引（インデックス）は使用されません

索引（インデックス）を作成すればパフォーマンスが向上するとは限りませんので、十分なパフォーマンスチューニング分析をしましょう

但し、索引（インデックス）項目はソート済みのため、ORDER　BYのような明示ソートやJOIN等で行われる暗示ソート項目として有効に機能することはありますので、索引（インデックス）の断片化は解消しておくことは有効です