1つのテーブルに定義できるセカンダリ インデックス、ハッシュ インデックス、および結合インデックスは32個までです(組み合わせは自由)。セカンダリ インデックスは固有(USI)または非固有(NUSI)にすることができます。この計算では、ORDER BY句を指定する複数列NUSIは2の連続するインデックスとみなされます。
これには、PRIMARY KEYおよびUNIQUE制約を実装するために使用される、システム定義のセカンダリ インデックスが含まれます。
テーブルにプライマリ インデックスを定義するものではないUNIQUE制約とPRIMARY KEY制約も、非テンポラル テーブルの場合、内部的にUSIとして定義されるので、この合計数に算入されます。これらの制約は内部的に単一テーブル結合インデックスとして定義されるので、すべてのUNIQUE制約またはPRIMARY KEY制約は、テーブルあたりセカンダリ インデックス、ハッシュ インデックス、および結合インデックスが32個までという合計数に算入されます。
BLOB列、CLOB列、BLOB列に基づくUDT列、CLOB列に基づくUDT列、PERIOD列、または地理空間列を、セカンダリ インデックスの列セットに含めることはできません。
システム派生のPARTITION列またはPARTITION#L n列は、セカンダリ インデックスの定義に含めることができません。
行レベル セキュリティ列は、セカンダリ インデックスの定義に含めることができます。
CREATE INDEX文を使用して、セカンダリ インデックスを既存のテーブルに追加できます(CREATE INDEXを参照)。
プライマリ インデックスではない固有性制約をテーブルに作成する場合、Teradata Databaseは、USIとして内部的に実装します。
- 固有セカンダリ インデックス
- UNIQUE NOT NULL制約
- PRIMARY KEY制約
行アクセスや結合のパフォーマンスを上げるような制約がある場合はいつでも、それらの制約をテーブルに追加することを検討してください。データベース制約のすべての機能は、クエリーの最適化に役立ちます。データベースに指定される制約が多いほど、クエリーの最適化を強化できる可能性が増大します。
固有性の制約を追加することの利点と思われる事項は、マルチセットNUPIテーブルに制限されません。さらに、SET NUPIテーブルを作成する場合、テーブルに固有性制約を指定しない限り、システムはデフォルトで重複行の検査を実行します。固有制約を実行することは、行の固有性を確立するために、システムの重複行検査よりもはるかにコストの低い方法です。
MultiLoadとFastLoadはプライマリ インデックス以外に固有性制約を持つターゲット テーブルをサポートしないので、行の固有性を確立するだけのためにマルチセットNUPIテーブルのプライマリ キーまたは代替キーに固有性制約を定義することは避けてください。MultiLoadとFastLoadのうちの1つ(一般的にはFastLoad)を使用することにより、ターゲット テーブルと基本的には同じでありながら、制約もトリガーもインデックスも定義されていないステージング テーブルに行をロードすれば、インデックスおよびトリガーに関連したMultiLoadおよびFastLoadの問題を回避できます。データをそのテーブルにロードした後、エラー ロギングで指定したINSERT … SELECTまたはMERGEのいずれかを使用することにより、目的の制約とインデックスが定義されたターゲット テーブルにデータを移動することができます。詳細は、<CREATE ERROR TABLE>および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>を参照してください。
さらに、参照先の実テーブルの列セットが更新されるたびにシステムはそのインデックス副次テーブルを保守する必要があるため、USIではパフォーマンス上のコストが発生します。
ALWAYS GENERATED … NO CYCLE識別列は、MultiLoadとFastLoadの両方によってサポートされるので、マルチセットNUPIテーブルの行を固有にするためのすぐれた選択肢です。しかし、識別列を使用して行アクセスまたは結合を促進することはできません。
- アプリケーション コードにより行の固有性を確立します。
- いかなる方法でも重複行を削除しないでおき、定期的に検証のクエリーをテーブルに対して実行して、重複行を検出します。 この方法は、以下の2つの事柄を前提とします。
- 使用するアプリケーション コードが、重複行を許容する。
- 重複行を識別する方法、およびテーブルで検出されたときにそれを除去する方法を知っている。
宣言制約の使用を避けてデータベースの整合性を保証しない重複行の管理手法は、以下のような理由で、実行しないことをお勧めします。
たとえば、非プライマリ インデックスの固有性制約をテーブルに定義する場合、MultiLoadまたはFastLoadを使用して行をテーブルにロードするにはまずそれらをすべて除去して、ロード操作の完了後に再作成する必要があります。
MultiLoadまたはFastLoad操作により重複行がテーブルにロードされた場合、そのテーブルに固有性制約を再作成できなくなります。最初に重複を検出して、その後それらをテーブルから除去しなければなりません。
- 重複行を検出して除去するアプリケーションが、企業内のすべてのアプリケーションに一様に導入されている。
- 重複行を検出して除去するアプリケーション コードが一様に導入されているにもかかわらず、すべての状況に適合している。
- データベースに対するすべての更新が、それらのアプリケーションによって行なわれる。このような前提条件を考えれば、アプリケーション ベースの重複行の検出および除去コードをバイパスする特別な対話式SQL更新を実行することは不可能です。
OLTPアプリケーションをサポートするワークロードのテーブルには、USIは一般に推奨されない。
各セカンダリ インデックスは、セカンダリ インデックス サブテーブルが関連付けられています。セカンダリ インデックス サブテーブルの各行には、インデックス付きの列値と、その値を含む基本テーブルのデータ行をポイントする1つ以上の行IDが含まれています(USIおよびNUPIサブテーブルの行レイアウトの詳細は、<Teradata Vantage™ - データベースの設計、B035-1094>を参照)。
セカンダリ インデックスの行タイプ | 行の格納先となるサブテーブル |
---|---|
USI | 参照する行とは異なるAMP。 これは一般に当てはまる点ですが、あらゆる場合に当てはまるとは限りません。USIの行が参照先の実テーブルの行と同じAMPに保存されることも、まれにですが、あります。パフォーマンス計画としては、セカンダリ インデックスのアクセスが常に2 AMP操作になるように検討するのが最善です。 これに当てはまらない例外的なケースは、USIがパーティション プライマリ インデックスと同じ列セットに対して定義されている場合に、パーティション列の一部がプライマリ インデックス列セットに含まれていないというケースです。 |
NUSI | 参照する行と同じAMP |
セカンダリ インデックスを使用すると、いわゆるセット選択(複数行の選択を意味するこの名称は、セットに0個または1個しか要素が含まれないことがあるため、技術的に適切な名称ではありません)のテーブル検索時間が大幅に短縮されます。ただし、セカンダリ インデックスを持つテーブルでの更新操作(削除、挿入、および更新を含む)にはより多くの入出力の処理が必要です。それは、一時的なジャーナリングが必要なこと、セカンダリ インデックス サブテーブルを更新することが必要となる可能性があること(インデックス付けされた列のセットが更新された場合)、およびフォールバック テーブルの更新などのためです。
USIサブテーブルはハッシュされ、単一の行または少数の行を選択する場合に大変効率的です。
NUSIビット マッピングは、複雑な条件式を非常に大きなテーブルに適用する場合に、効率的な検索を可能にします。選択性の弱い複数のNUSIを重複させ、ビット マッピングすることによって、強い選択性を得ることができます。
- 文字の大小の区別がある値を含めること
- NOT CASESPECIFIC列セットでテーブルを対象にすること
ALLオプションを指定すると、追加のインデックスの記憶領域が必要となる場合もあることに注意してください。
ALLオプションの存在のみが異なる複数のNUSIを指定することはできません。
セカンダリ インデックスの使用が効果的であるかを実行前に必ず確認します。
セカンダリ インデックスの詳細については、<Teradata Vantage™ - データベースの設計、B035-1094>を参照してください。