私は Oracle のバックグラウンドを持っており、すべてのテーブルに「インデックス付きの整理されたテーブル」(IOT) を使用することは、Oracle では不合理に聞こえますが、実際にこれを見たことはありません。SQL Server では、私が扱ったすべてのデータベースのすべてのテーブルにクラスター化インデックスがあり、これは (概念的には) IOT と同じです。
何故ですか？どこでもクラスター化インデックスを使用する理由はありますか? 私には、ほんの一握りのケースにしか適していないように思えます。
ありがとう
クラスター化インデックスは、インデックス構成テーブルとまったく同じではありません。IOT では、すべてのフィールドが IOT キーに参加する必要があります。SQL Server のクラスター化インデックスは一意である必要はなく、主キーである必要もありません。
クラスター化インデックスは SQL Server で広く使用されています。これは、一般的に使用されるクエリをより効率的にする自然な順序付けがほとんど常に存在するためです。オラクルの IOT はより多くの荷物を運ぶため、それほど有用ではありませんが、一般的に認められているよりも有用である可能性があります。
歴史的に、6.5 または 7.0 より前の非常に古いバージョンの SQL Server IIRC は、行レベルのロックをサポートしておらず、テーブルまたはページ レベルでしかロックできませんでした。多くの場合、クラスター化されたインデックスを使用して、書き込みがテーブルの物理ストレージ全体に分散され、ページ ロックの競合が最小限に抑えられます。ただし、SQL Server 6 は数年前にサポートが終了したため、この問題のあるアプリケーションはまれなレガシー システムに限定されます。
クラスター化インデックスがない場合、テーブルはヒープとして編成されます。これは、挿入されるすべての行がテーブルの最後のデータ ページに追加されることを意味します。また、行が更新されると、更新されたデータが以前よりも大きい場合、行はテーブルの最後のデータ ページに移動されます。
クラスタ化インデックスを持たない方がよい場合
可能な限り高速な挿入が必要であるが、更新と読み取りの速度が犠牲になる可能性があるテーブルがある場合は、クラスター化されたインデックスがなくてもうまくいく可能性があります。1 つの例は、キューとして使用されていたテーブルがある場合です。たとえば、後で読み取られて別のテーブルに移動されるだけの多数の挿入があります。
クラスタ化インデックス
クラスター化インデックスは、クラスター化インデックスの列に基づいて、テーブル内のデータを編成します。たとえば、uniqueidentifier などの間違ったものにクラスターを作成すると、速度が低下する可能性があります (以下を参照)。
クラスター化インデックスが検索に最も一般的に使用される値にあり、それが一意であり、増加している限り、クラスター化インデックスから驚くべきパフォーマンス上の利点が得られます。たとえば、一般的に USER_ID に基づいてユーザー データを検索する USERS というテーブルがある場合、USER_ID でクラスタリングすると、これらすべての検索のパフォーマンスが向上します。これにより、データを取得するために読み取る必要があるデータ ページの数が減ります。
クラスター化インデックスにキーが多すぎると、速度が低下する可能性もあります。
クラスター化インデックスの一般的なルール:
varchar 列にクラスター化しないでください。
通常は、INT IDENTITY 列でのクラスタリングが最適です。
よく検索するものに集中します。
UniqueIdentifier でのクラスタリング
インデックスに一意の識別子を使用すると、自然な並べ替え順序がないため、非常に非効率的です。インデックスの B ツリー構造に基づいて、uniqueidentifiers を使用すると、非常に断片化されたインデックスになります。再構築または再編成した後でも、それらは依然として非常に断片化されています。そのため、インデックスが遅くなり、断片化のためにメモリとディスク上で非常に巨大になります。また、uniqueidentifier の挿入では、インデックスでページ分割が発生する可能性が高くなり、挿入が遅くなります。一般に、一意の識別子はインデックスにとって悪いニュースです。
概要
私の推奨事項は、本当に正当な理由 (キューとして機能するテーブル) がない限り、すべてのテーブルにクラスター化インデックスを配置することです。
ほとんどの場合、クラスター化されたインデックスよりもヒープを好む理由がわかりません。クラスタリングを使用すると、選択した 1 つのインデックスを無料で取得できます。ほとんどの場合、これは主キーです (おそらく強制したいでしょう!)。
ヒープは主に特殊な状況向けです。
リレーショナル データベースで主キーを使用しており、一般に、これらの主キーを介して関係が確立されます。ほとんどの人は、最初のフィールドに TableID という名前を付けて、それを主キーにしていました。クエリで 2 つ以上のテーブルを結合する場合、クラスター化インデックスを使用すると最速の結果が得られます。