固有基本索引(UPI) |
- SQL文にPI値が組み込まれている場合、最も効率的なアクセス方法である
- 1つのAMPと1つの行を使用する
- スプール ファイルが不要(単純なSELECTの場合)
- 最も精度の良いロックを取得できる
|
PI値を指定するSELECT文で使われる場合はなし。ただし、PIの選択が不十分だと、大きな作業負荷の場合に全体的な性能が低下することがある。 |
非固有基本索引(NUPI) |
- SQL文にPI値が組み込まれている場合、効率的にアクセスできる
- 1つのAMPを使用する
- 精度の良いロックを取得できる
- 返される行数が少なければ、スプール ファイルが不要な場合もある
|
- USIのないSET表の場合、INSERTが低速になる可能性がある
- PI値の重複行が多い場合、PI値を含むSELECTの効率が低下する可能性がある
|
固有副次索引(USI) |
- SQL文にUSI値が組み込まれている場合、効率的にアクセスでき、PI値を指定する必要はない
- 2つのAMPと1つの行を使用する
- スプール ファイルが不要(単純なSELECTの場合)
|
INSERT、UPDATE、MERGE、DELETE文に対して追加のオーバーヘッドが必要となる |
非固有副次索引(NUSI) |
- 表内の値あたりの行数が比較的少ない場合は、効率的にアクセスできる
- すべてのAMPと、おそらくは複数の行を使用する
- UPI値よりも即座に使用できる可能性のある情報(例えば、従業員番号ではなく、従業員の姓など)を使用してアクセスできる
- スプール ファイルが必要な場合がある
|
- INSERT、UPDATE、MERGE、DELETE文に対して追加のオーバーヘッドが必要となる
- アクセスされるデータ ブロック数が表内のデータ ブロックのかなり大きい割合を占める場合、最適化ルーチンはフル テーブル スキャンの方が負担が軽いと判断するので、この索引は最適化ルーチンで使用されないことになる
|
フル テーブル スキャン |
- 各行のアクセス回数は1回のみである
- 任意の列条件セットを使用してアクセスできる
|
- すべての行が検査対象となる
- 通常は、実表と同程度の大きさのスプール ファイルが必要となる
|
複数表結合索引(JI) |
- 特定の結合と集約を繰り返し実行する必要性を排除できる
- 実表を参照せずに問合わせを処理できる場合がある
- PIが実表のものと異なってもよい
- NUSIまたはUSIの代用になる
|
- その複数表JIに関与するすべての実表について、INSERT、UPDATE、MERGE、DELETE文に対して追加のオーバーヘッドが必要となる
- 一般に、INSERT、UPDATE、MERGE、DELETE文の処理が毎日大量に行なわれる表のデータには適さない
- 実表に対して実行される操作について、ある程度の制約が課せられる
|
単一表結合索引(JI) または
ハッシュ索引
|
- 使用頻度の高い列(またはJI値のみの集約処理)を、使用頻度の低い列から切り離すことができる
- 使用頻度の高い列のみを参照する場合、物理的なI/Oの回数を削減できる
- PIが実表のものと異なってもよい
|
- INSERT、UPDATE、MERGE、DELETE文に対して追加のオーバーヘッドが必要となる
- 実表に対して実行される操作について、ある程度の制約が課せられる
|
スパース結合索引(JI) |
- 通常のJIよりも格納領域が小さくて済む
- 通常のJIと比較すれば、実表に対するINSERT、UPDATE、MERGE、DELETE文に伴なう追加のオーバーヘッドが削減される
- 頻出する重複値を除外することにより、最適化ルーチンがJIを他の頻出度の低い値へのアクセスに使用するようにできる
|
- 実表に対するINSERT、UPDATE、MERGE、DELETE文に対して追加のオーバーヘッドが必要となる
- 実表に対して実行される操作について、ある程度の制約が課せられる
|