クラスタ化インデックスSQL Server

Question

私はOracleのバックグラウンドを持っており、すべてのテーブルに「索引構成表」（IOT）を使用すると、Oracleでは不合理に聞こえます。 SQL Serverでは、私が取り組んだデータベースはすべて、IOT（概念的には）と同じ、すべてのテーブルにクラスタ化されたインデックスを持っています。

なぜですか？どこでもクラスタ化インデックスを使用する理由はありますか？少数のケースにしか役に立たないように私には思える。私たちは、リレーショナル・データベースにし、一般的な関係で主キーを使用している

おかげ

Answer 1

クラスタ化インデックスがない場合、テーブルはヒープとして編成されます。つまり、挿入されているすべての行が、表の最後のデータページに追加されます。また、行が更新されると、更新されたデータが以前よりも大きければ、表の最後のデータページに移動します。

あなたが最速の挿入を必要とするテーブルを持っていますが、更新を犠牲にし、スピードを読み取ることができ、その後、クラスタ化インデックスは、のために働くことがない場合は、クラスタ化インデックス

を持っていないのは良いです君は。 1つの例は、キューとして使用されていたテーブルがある場合です。たとえば、多くの挿入が後で読み込まれて別のテーブルに移動されるなどです。

クラスタ化インデックス

クラスタ化インデックスは、クラスタ化インデックスの列に基づいて、テーブル内のデータを整理します。あなたがユニークな識別子のように間違ったことをすると、これは物事を遅くすることができます（下記参照）。

クラスタ化インデックスが検索に最も一般的に使用される値であり、一意であり、それらを増やすと、クラスター化インデックスのパフォーマンスが向上します。たとえば、USER_IDに基づいてユーザーデータを検索するUSERSというテーブルがある場合、USER_IDでクラスタリングすると、すべてのルックアップのパフォーマンスが向上します。これにより、データを読み込むために必要なデータページの数が単純に削減されます。

クラスタ化インデックスにキーが多すぎると、状況が遅くなる可能性があります。クラスタ化インデックスの

一般規則：

は、任意のvarchar列にクラスタ化しないでください。

通常、INT IDENTITY列でのクラスタリングが最適です。

あなたが一般的に検索しているものに集中してください。インデックス内のuniqueidentifiersでUniqueIdentifiers

上

クラスタリング全く自然なソート順がないため、彼らは非常に非効率的です。索引のbツリー構造に基づいて、uniqueidentifierを使用するときわめて断片化された索引が作成されます。再構築または再編成後、それらは依然として非常に細分化されています。だから、インデックスが遅くなり、断片化のためにメモリとディスクに膨大な量になってしまいます。また、uniqueidentifierの挿入時には、インデックス上のページ分割によって結局挿入が遅くなる可能性が高くなります。一般的に、uniqueidentifierはインデックスの悪いニュースです。

まとめ

私の推薦はない（キューとして機能すなわちテーブル）には本当に十分な理由がある場合を除き、すべての表がそれにクラスタ化インデックスを持つべきであるということです。

Answer 2

は、これらの主キーを介して確立されます。ほとんどの人は、TableIDとして最初のフィールドに名前を付けてそれを主キーにしていました。クエリで2つ以上のテーブルを結合すると、クラスタ化インデックスを使用すると最も速く結果が得られます。

Answer 3

ほとんどの場合、クラスタ化インデックスよりもヒープを好む理由はわかりません。クラスタリングを使用すると、自由に1つの索引を選択できます。ほとんどの場合、これはプライマリキーです（これはおそらく実行する必要があります）。

ほとんどの場合、特殊な状況のためです。

Answer 4

クラスタ化インデックスは、インデックス構成テーブルとまったく同じものではありません。 IOTでは、すべてのフィールドがIOTキーに参加しなければなりません。 SQL Serverのクラスタード・インデックスは一意である必要はなく、主キーである必要はありません。

一般的に使用されるクエリをより効率的にする自然な順序付けがほとんど存在するため、クラスタ化インデックスはSQL Serverで広く使用されています。オラクルのIOTはより多くの手荷物を運ぶので、一般的に信用されているほうが便利かもしれませんが、それほど有用ではありません。

以前のSQL Server 6.5より前のバージョンまたは7.0 IIRCでは、行レベルのロックがサポートされておらず、テーブルまたはページレベルでしかロックできませんでした。多くの場合、ページロックに対する競合を最小限に抑えるために、クラスタ化インデックスを使用して、書き込みがテーブルの物理ストレージに散在するようにします。しかし、SQL Server 6は数年前にサポートを受けていたため、この問題のあるアプリケーションはまれなレガシーシステムに限定されていました。