これをSQLServerMVPのBradMcGeheeよりも簡潔に述べるのは難しいです：
経験則として、すべてのテーブルにはクラスター化されたインデックスが必要です。 常にではありませんが、一般的に、クラスター化インデックスは、単調に増加する列（ID列、または値が増加している他の列など）にあり、一意である必要があります。多くの場合、主キーはクラスター化インデックスの理想的な列です。
BOLはこの感情を反映しています：
いくつかの例外を除いて、すべてのテーブルにクラスター化されたインデックスが必要です。
これを行う理由はたくさんあり、主にクラスター化されたインデックスがストレージ内のデータを物理的に順序付けるという事実に基づいています。 。
-
クラスタ化インデックスが単一の列にある場合、単調に増加し、ストレージデバイスで順番に挿入が行われ、ページ分割は発生しません。
-
クラスター化インデックスは、主キーに基づいて行を選択する一般的なパターンなど、インデックス値が一意である場合に特定の行を見つけるのに効率的です。
-
クラスタ化インデックスを使用すると、値の範囲（
between）で検索されることが多い列に対して効率的なクエリを実行できることがよくあります。 、> など）。 -
クラスタリングにより、データが特定の1つまたは複数の列で一般的に並べ替えられるクエリを高速化できます。
-
クラスタ化されたインデックスは、テーブルの断片化を制御するために、オンデマンドで再構築または再編成できます。
-
これらの利点は、ビューにも適用できます。
クラスター化されたインデックスを次の場所に配置したくない場合があります：
-
SQL Serverはストレージ内のデータを物理的に並べ替える必要があるため、データが頻繁に変更される列。
-
すでに他のインデックスでカバーされている列。
-
クラスター化されたインデックスは非クラスター化されたインデックスのルックアップでも使用されるため、ワイドキー。
-
newsequentialid（）ですが、IDよりも大きく、事実上ランダムな値（ソートされる可能性は低い）のGUID列 挿入中の物理的な並べ替えを軽減するために使用できます。 -
ヒープ（クラスター化インデックスのないテーブル）を使用するまれな理由は、データが常に非クラスター化インデックスを介してアクセスされ、RID（SQL Server内部行識別子）がクラスター化インデックスキーよりも小さいことがわかっている場合です。
これらの考慮事項や、特定のアプリケーションワークロードなどの他の考慮事項があるため、クエリで最大のメリットを得るには、クラスター化インデックスを慎重に選択する必要があります。
また、 SQL Serverのテーブルに主キーを作成すると、デフォルトで一意のクラスター化インデックスが作成されることに注意してください （まだ持っていない場合）。つまり、クラスター化インデックスを持たないが、主キーを持っている（すべてのテーブルがそうであるように）テーブルを見つけた場合、開発者は以前にその方法で作成することを決定していました。あなたはそれを変えるための説得力のある理由を持ちたいかもしれません（私たちが見てきたように、その多くがあります）。 クラスター化されたインデックスを追加、変更、または削除するには、テーブル全体を書き換える必要があります クラスター化されていないインデックスがあるため、大きなテーブルでは時間がかかる場合があります。