クラスタ化インデックスのないテーブル（ヒープテーブル）では、データページは相互にリンクされません。したがって、ページをトラバースするには、インデックス割り当てマップの検索 。
ただし、クラスター化されたテーブルには、二重リンクリストにリンクされたデータページがあります -シーケンシャルスキャンを少し速くします。もちろん、その代わりに、INSERTでデータページを順番に保持するというオーバーヘッドがあります。 、UPDATE 、およびDELETE 。ただし、ヒープテーブルにはIAMへの2回目の書き込みが必要です。
クエリにRANGEがある場合 演算子（例：SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ）の場合、クラスター化されたテーブル（順序が保証されている）の方が効率的です。インデックスページを使用して関連するデータページを見つけることができるためです。ヒープは順序付けに依存できないため、すべての行をスキャンする必要があります。
そしてもちろん、クラスター化インデックスを使用すると、クラスター化インデックスシークを実行できます。これは、パフォーマンスに非常に最適です...インデックスのないヒープは、常にテーブルスキャンになります。
だから：
-
すべての行を選択するクエリ例の場合、唯一の違いは、クラスター化インデックスが維持する二重リンクリストです。これにより、クラスター化されたテーブルは、行数が多いヒープよりもわずかに高速になります。
-
WHEREを使用したクエリの場合 クラスタ化されたインデックスによって（少なくとも部分的に）満たすことができる句は、順序付けのために先に出てくるので、テーブル全体をスキャンする必要はありません。 -
クラスタ化インデックスで満たされないクエリの場合、ほぼ均等です...繰り返しますが、唯一の違いは、シーケンシャルスキャン用の二重リンクリストです。どちらの場合も、あなたは最適ではありません。
-
INSERTの場合 、UPDATE、およびDELETEヒープが勝つかもしれないし、勝てないかもしれない。ヒープは順序を維持する必要はありませんが、IAMへの2回目の書き込みが必要です。相対的なパフォーマンスの違いはごくわずかだと思いますが、データにもかなり依存します。
Microsoftには、ホワイトペーパー があります。 これは、クラスター化されたインデックスをヒープ上の同等の非クラスター化インデックスと比較します（上記で説明したものとまったく同じではありませんが、閉じています）。彼らの結論は、基本的にすべてのテーブルにクラスター化されたインデックスを配置することです。結果を要約するために最善を尽くします（ここでも、非クラスター化インデックスをクラスター化インデックスと実際に比較していることに注意してください。ただし、比較的比較可能だと思います）：
-
INSERTパフォーマンス：ヒープに2回目の書き込みが必要なため、クラスター化されたインデックスは約3％勝ちます。 -
UPDATEパフォーマンス：ヒープに必要な2回目のルックアップにより、クラスター化インデックスは約8％勝ちます。 -
DELETEパフォーマンス：クラスター化されたインデックスは、ヒープのIAMからの2回目のルックアップと2回目の削除が必要なため、約18％勝ちます。 - 単一の
SELECTパフォーマンス：ヒープに必要な2回目のルックアップにより、クラスター化インデックスは約16％勝ちます。 - 範囲
SELECTパフォーマンス：ヒープのランダムな順序により、クラスター化されたインデックスが約29％勝ちます。 - 同時
INSERT：クラスター化されたインデックスのページ分割により、ヒープテーブルは負荷がかかった状態で30％勝ちます。