25

最近、データベース内にクラスター化インデックスが定義されていないテーブルがいくつか見つかりました。ただし、非クラスター化インデックスが定義されているため、HEAP 上にあります。

分析の結果、select ステートメントが、非クラスター化インデックスで定義された列に対してフィルターを使用していることがわかりました。

これらのテーブルにクラスター化インデックスがないと、パフォーマンスに影響しますか?

4

6 に答える 6

56

これをSQLServerMVPのBradMcGeheeよりも簡潔に述べるのは難しいです。

経験則として、すべてのテーブルにはクラスター化されたインデックスが必要です。常にではありませんが、一般的に、クラスター化インデックスは、単調に増加する列（ID列、または値が増加している他の列など）にあり、一意である必要があります。多くの場合、主キーはクラスター化インデックスの理想的な列です。

BOLはこの感情を反映しています。

いくつかの例外を除いて、すべてのテーブルにクラスター化されたインデックスが必要です。

これを行う理由はたくさんあり、主にクラスター化されたインデックスがストレージ内のデータを物理的に順序付けるという事実に基づいています。

  • クラスタ化インデックスが単調に増加する単一の列にある場合、挿入はストレージデバイス上で順番に発生し、ページ分割は発生しません。

  • クラスター化インデックスは、主キーに基づいて行を選択する一般的なパターンなど、インデックス値が一意である場合に特定の行を見つけるのに効率的です。

  • クラスタ化インデックスを使用すると、値の範囲（ 、、など）を検索することが多い列に対して効率的なクエリを実行できることがよくあります。between>

  • クラスタリングは、データが特定の1つまたは複数の列によって一般的にソートされるクエリを高速化できます。

  • クラスタ化されたインデックスは、テーブルの断片化を制御するために、オンデマンドで再構築または再編成できます。

  • これらの利点は、ビューにも適用できます。

次の場所にクラスター化されたインデックスを設定したくない場合があります。

  • SQL Serverはストレージ内のデータを物理的に並べ替える必要があるため、データが頻繁に変更される列。

  • すでに他のインデックスでカバーされている列。

  • クラスター化されたインデックスは非クラスター化されたインデックスルックアップでも使用されるため、ワイドキー。

  • GUID列は、IDよりも大きく、効果的にランダムな値（ソートされる可能性は低い）ですが、newsequentialid()挿入中の物理的な並べ替えを軽減するために使用できます。

  • ヒープ（クラスター化インデックスのないテーブル）を使用するまれな理由は、データが常に非クラスター化インデックスを介してアクセスされ、RID（SQL Server内部行識別子）がクラスター化インデックスキーよりも小さいことがわかっている場合です。

これらの考慮事項や特定のアプリケーションワークロードなどの他の考慮事項があるため、クエリで最大のメリットを得るには、クラスター化インデックスを慎重に選択する必要があります。

また、SQL Serverのテーブルに主キーを作成すると、デフォルトで一意のクラスター化インデックスが作成されることに注意してください（まだ作成されていない場合）。これは、クラスター化インデックスを持たないが、（すべてのテーブルがそうであるように）主キーを持っているテーブルを見つけた場合、開発者は以前にその方法で作成することを決定したことを意味します。あなたはそれを変えるための説得力のある理由を持ちたいかもしれません（私たちが見てきたように、その多くがあります）。クラスタ化インデックスを追加、変更、または削除するには、テーブル全体と非クラスタ化インデックスを書き換える必要があるため、大きなテーブルでは時間がかかる場合があります。

于 2012-08-06T20:51:41.563 に答える
4

「すべてのテーブルにクラスター化インデックスが必要です」とは言いません。ジョーカーのように、テーブルごとに 1 つのジョーカーしかありませんが、使用する必要はありません。他のデータベース システムには、少なくともこの形式では、これはありません。

何をしているのかを理解せずにクラスタ化されたインデックスをどこにでも配置すると、パフォーマンスが低下する可能性があります (一般に、クラスタ化されたインデックスはディスク上の物理的な並べ替えを意味するため、または少なくともそれを理解するための良い方法であるため、INSERT のパフォーマンスが低下します)。たとえば、ますます多く見られるように、GUID プライマリ キーを使用します。

それで、Tim Lehner の例外と理由を読んでください。

于 2012-08-07T16:38:04.157 に答える
1

はい、テーブルにクラスター化インデックスが必要です。これにより、すべての非クラスター化インデックスのパフォーマンスが向上します。

于 2012-08-03T01:45:40.153 に答える
1

パフォーマンスは大きな毛むくじゃらの問題です。正しいことのために最適化していることを確認してください。

無料のアドバイスは常にその価値があり、実際の実験に代わるものはありません。

インデックスの目的は、一致する行を見つけて、見つかったデータを取得できるようにすることです。

検索条件にクラスター化されていないインデックスを使用すると、行を見つけるのに役立ちますが、行のデータを取得するには追加の操作が必要です。

クラスター化インデックスがない場合、SQL は内部 rowId を使用してデータの場所を指します。

ただし、テーブルにクラスター化インデックスがある場合、その rowId はクラスター化インデックスのデータ値に置き換えられます。

したがって、行データを読み取るステップは必要なく、インデックスの値によってカバーされます。

クラスター化インデックスが選択性に優れていなくても、これらのキーが頻繁に要求される結果のほとんどまたはすべてである場合は、それらを非クラスター化インデックスのリーフとして使用すると役立つ場合があります。

于 2012-08-06T20:13:30.950 に答える
0

はい、すべてのテーブルにクラスター化インデックスが必要です。クラスター化インデックスは、テーブル内のデータの物理的な順序を設定します。これは、店でのバンド名順やラストネーム順のイエローページと比較することができます。これは物理的な順序を扱うため、1 つしか持つことができず、多くの列で構成できますが、持つことができるのは 1 つだけです。

クラスター化インデックスは、値の範囲を頻繁に検索する列に配置することをお勧めします。例は日付範囲です。クラスター化インデックスは、インデックス値が一意である場合に特定の行を見つけるのにも効率的です。クラスター化インデックスが定義されていない場合、Microsoft SQL は PRIMARY KEY 制約にクラスター化インデックスを自動的に配置します。

クラスタ化インデックスは、次の場合には適していません。

頻繁に変更される列

  • これにより、行全体が移動します (SQL Server は行のデータ値を物理的な順序で保持する必要があるため)。これは、データが不安定になりがちな大量のトランザクション処理システムでは重要な考慮事項です。

ワイドキー

  • クラスター化インデックスのキー値は、すべての非クラスター化インデックスでルックアップ キーとして使用されるため、各非クラスター化インデックス リーフ エントリに格納されます。
于 2012-08-06T21:15:00.143 に答える
0

clustered index多数の個別の値を含む when 列の使用を検討してください。これにより、SQL Server がキー値を複製するために「一意化子」を追加する必要がなくなります。

短所: クラスタリング インデックスのフィールドが変更された場合のみ、レコードの更新に時間がかかります。

ほぼ同じクラスタリング インデックス値で多数の同時挿入が発生するリスクがあるクラスタリング インデックスの構築を避ける

非クラスター化インデックスに対する検索は、クラスター化インデックスが正しく構築されていない場合、または呼び出し元のアプリケーションにデータを返すために必要なすべての列が含まれていない場合、遅くなるように見えます。非クラスター化インデックスに必要なすべてのデータが含まれていない場合、SQL Server はクラスター化インデックスにアクセスして不足しているデータを取得します (ルックアップを介して)。これにより、ルックアップが行で実行されるため、クエリの実行が遅くなります。行ごと。

于 2012-08-03T09:48:46.923 に答える