索引のタイプの比較 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - データベース入門

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
2021年7月
Language
日本語
Last Update
2022-01-13
dita:mapPath
ja-JP/jiv1600056352873.ditamap
dita:ditavalPath
ja-JP/wrg1590696035526.ditaval
dita:id
B035-1091
Product Category
Software
Teradata Vantage

Teradata Databaseでは、個別の問合わせについての索引の使用方法をユーザーが明示的に指示する必要はなく、そのようなユーザーによる指示を許容することもありません。最適化ルーチンが妥当と思われる全選択肢のコストを算定し、最も低コストで済むと評価した使用方法を選択するという仕組みになっています。

すべての問合わせ計画の目的は、正確な結果をできるだけ迅速に返すことにあります。したがって、最適化ルーチンが索引(複数の場合あり)を使用するのは、索引が問合わせの処理を高速化する場合に限られます。最適化ルーチンでは、索引を一切使用せずに問合わせが処理されることもあります。

問合わせ計画に対する最適化ルーチンの索引選択には以下の特性があります。
  • Teradata Database全体の性能に直接影響する
  • 単純な処理でないこともある
  • ある程度使用予測を基にする

下表では、単純なSELECT文を実行するものと仮定し、様々な索引手法のいくつかについて、長所と短所を説明します。

アクセス方法 長所 短所
固有基本索引(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文に対して追加のオーバーヘッドが必要となる
  • 実表に対して実行される操作について、ある程度の制約が課せられる