6

多くの場所で、BETWEEN ステートメントを使用して行の範囲を選択するためにクラスター化インデックスを使用することをお勧めします。このクラスター化インデックスが使用されるような方法で外部キー フィールドによる結合を選択すると、クラスター化も役立つはずです。これは、すべて同じクラスター化キー値があり、BETWEEN が使用されていないにもかかわらず、行の範囲が選択されているためです。

join を使用して選択したものだけを気にし、他には何も気にしないことを考えると、私の推測は間違っていますか?

4

5 に答える 5

10

この種の問題を絶対的に議論することはあまり役に立ちません。

それは常にケースバイケースの状況です！

基本的に、クラスター化されたインデックスを介したアクセスにより、1つの間接的な期間が節約されます。

JOINで使用されるキーがクラスター化インデックスのキーであると仮定すると、1回の読み取りで[インデックスシークからか、スキャンまたは部分スキャンからかは関係ありません]、行全体（レ​​コード）を取得します。

クラスタ化インデックスの問題の1つは、テーブルごとに1つしか取得できないことです。したがって、それを賢く使う必要があります。実際、場合によっては、INSERTのオーバーヘッドと断片化（キーや新しいキーの順序などによって異なります）のために、クラスター化されたインデックスをまったく使用しない方が賢明です。

場合によっては、クラスター化インデックスと同等のメリットが得られます。カバーリングインデックス、つまり目的のキーシーケンスのインデックスの後に、関心のある列値が続きます。クラスター化インデックスと同様に、カバーリングインデックスはそうではありません。基になるテーブルへの間接参照が必要です。実際、カバーリングインデックスは小さいため、クラスター化インデックスよりもわずかに効率的である可能性があります。
ただし、クラスター化インデックスと同様に、ストレージオーバーヘッドは別として、INSERT（およびDELETEまたはUPDATE）クエリ中に追加のインデックスに関連するパフォーマンスコストが発生します。

そして、はい、他の回答で示されているように、クラスター化インデックスに使用されるキーの「外部キー性」は、インデックスのパフォーマンスとはまったく関係がありません。FKは、データベースの整合性の維持を容易にすることを目的とした制約ですが、基になるフィールド（列）は、それ以外はテーブル内の他のフィールドとまったく同じです。

インデックス構造について賢明な決定を下すには、

  • さまざまなインデックスタイプ（およびヒープ）がどのように機能するかを理解するため
    （そして、ところで、これはSQL実装間で多少異なります）
  • 手元にあるデータベースの統計プロファイルの良いイメージを持っていること：
    関係である大きなテーブル、関係の平均/最大カーディナリティ、データベースの典型的な成長率など。
  • to have good insight regarding the way the database(s) is (are) going to be be used/queried

Then and only then, can one can make educated guesses about the interest [or lack thereof] to have a given clustered index.

于 2010-03-11T22:24:32.267 に答える
3

別の質問をしたいのですが、単一の JOIN を高速化するためだけに、クラスター化インデックスを外部キー列に配置するのが賢明でしょうか? それはおそらく役に立ちますが、...価格で！

クラスター化インデックスは、すべての操作でテーブルを高速化します。はい！します。背景情報については、 Kim Tripp の優れたThe Clustered Index Debate continueを参照してください。彼女は、クラスター化インデックスの主な基準についても言及しています。

  • 狭い
  • 静的 (変化しない)
  • 個性的
  • 可能であれば：増え続ける

INT IDENTITY はこれを完全に満たしますが、GUID はそうではありません。詳細な背景情報については、主キーとしての GUIDを参照してください。

なぜ狭い？クラスター化キーは、同じテーブルのすべての非クラスター化インデックスのすべてのインデックス ページに追加されるため (必要に応じて、データ行を実際に検索できるようにするため)。クラスタリングキーに VARCHAR(200) を入れたくない....

なぜユニークなの?? 上記を参照してください。クラスタリング キーは、SQL Server がデータ行を一意に検索するために使用するアイテムおよびメカニズムです。一意である必要があります。一意でないクラスタリング キーを選択すると、SQL Server 自体が 4 バイトの一意識別子をキーに追加します。気をつけて！

これらが私の基準です。クラスター化キーを、狭く、安定した、一意の、できれば増え続ける列に配置してください。外部キー列がそれらと一致する場合-完璧です!

ただし、どのような状況でも、クラスター化キーをワイドまたは複合外部キーに配置することはありません。注意: クラスタリング キーの値は、そのテーブルのすべての非クラスタ化インデックス エントリに追加されます。クラスター化されていないインデックスが 10 個あり、テーブルに 100,000 行ある場合、これは 100 万エントリです。それが 4 バイトの整数か、200 バイトの VARCHAR - HUGE かによって、大きな違いが生じます。ディスク上だけでなく、サーバー メモリ内でも同様です。クラスタ化インデックスを何にするかについて、非常に慎重に検討してください。

SQL Server は一意識別子を追加する必要があるかもしれません - さらに悪いことになります。値が変更されると、SQL Server は多くの簿記と更新をあちこちで行う必要があります。

要するに：

  • 外部キーにインデックスを付けることは間違いなく素晴らしいアイデアです - 常にそうしてください!
  • それをクラスター化インデックスにすることには非常に注意を払います。まず、クラスター化されたインデックスは 1 つしか取得できないため、どの FK リレーションシップを選択しますか? また、クラスタリング キーを幅広で絶えず変化する列に配置しないでください。
于 2010-03-12T06:18:01.540 に答える
2

インデックス自体が順序付けられているため、FK 列のインデックスは JOIN に役立ちます。クラスター化されているということは、ディスク (リーフ) 上のデータが B ツリーではなく順序付けられていることを意味します。

それをカバリング インデックスに変更すると、クラスタ化されたものとクラスタ化されていないものは無関係になります。重要なのは、有用な索引を持つことです。

于 2010-03-11T22:11:43.900 に答える
1

データベースの実装に依存します。

SQL Server の場合、クラスター化インデックスは、データがページとして格納されるデータ構造であり、B ツリーがあり、別のデータ構造として格納されます。高速なパフォーマンスが得られる理由は、チェーンの先頭にすばやく到達でき、範囲が簡単にリンクされたリストであるためです。

非クラスター化インデックスは、実際のレコードへのポインターを含むデータ構造であり、さまざまな懸念があります。

Clustered Index Structuresに関するドキュメントを参照してください。

インデックスは、外部キーの関係に関しては役に立ちませんが、「カバーされた」インデックスの概念により役立ちます。WHERE 句にインデックスに基づく制約が含まれている場合。返されたデータセットをより速く生成できます。そこからパフォーマンスが生まれます。

于 2010-03-11T22:11:51.997 に答える
0

通常、クラスタ内でデータを順番に選択すると、パフォーマンスが向上します。また、テーブル (データ) のサイズと between ステートメントの条件に完全に依存します。

于 2010-03-11T22:08:05.997 に答える