SQL SERVER 2005 データベース用のデータベース作成スクリプトをいくつか継承しました。
私が気づいたことの 1 つは、すべての主キーがNON CLUSTEREDクラスター化ではなくインデックスとして作成されることです。
テーブルごとにクラスター化インデックスを 1 つしか持つことができず、検索のクエリ パフォーマンスなどのために非主キー列にクラスター化インデックスを配置したい場合があることはわかっています。ただしCLUSTERED、問題のテーブルには他のインデックスはありません。
したがって、私の質問は、上記とは別に、主キー列にクラスター化インデックスを持たない技術的な理由はありますか?
「通常の」データまたはルックアップ テーブル: いいえ、理由はわかりません。
一括インポート テーブルや一時テーブルなどについては、場合によって異なります。
驚いたことに、優れたクラスター化インデックスを使用すると、INSERT や UPDATE などの操作を実際に高速化できるように見える人もいます。Kimberly Tripps の優れた記事を参照してください。クラスター化されたインデックスの議論は続きます....ブログ投稿で、彼女はなぜこれが当てはまるのかを非常に詳細に説明しています。
この観点から： SQL Serverテーブルに適切なクラスター化インデックス（狭く、安定し、一意で、増加し続ける=最も明白な選択肢として）を持たない正当な理由はわかりません。INT IDENTITY
クラスタリング キーを選択する方法と理由について深い洞察を得るには、このトピックに関する Kimberly Tripp の優れたブログ投稿をすべてお読みください。
http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx
http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx
"Queen of Indexing" の素晴らしい作品です ! :-)
(主題に関する良い記事はwww.mssqltips.comにあります)
HEAP テーブル (クラスター化インデックスなし)
データは特定の順序で保存されません
非クラスタ化インデックスも存在しない限り、特定のデータをすばやく取得できない
データ ページはリンクされていないため、シーケンシャル アクセスではインデックス アロケーション マップ (IAM) ページを参照する必要があります。
クラスタ化されたインデックスがないため、インデックスを維持するための追加の時間は必要ありません
クラスター化インデックスがないため、クラスター化インデックス ツリーを格納するための追加の領域は必要ありません。
これらのテーブルには、sys.indexes カタログ ビューで 0 の index_id 値があります。
クラスター化されたテーブル
データはクラスタ化されたインデックス キーに基づいて順番に格納されます
クエリがインデックス付きの列を使用する場合、クラスター化されたインデックス キーに基づいてデータをすばやく取得できます。
より高速なシーケンシャル アクセスのためにデータ ページがリンクされている
クラスター化されたインデックス ツリーを格納するには、追加の領域が必要です これらのテーブルには、sys.indexes カタログ ビューで 1 の index_id 値があります
「クラスター化されたテーブルのデータ行に直接アクセスできない-なぜですか?」の下の私の回答を読んでください。、 最初。具体的には【2】注意事項です。
「データベース」を作成したのはクレチンです。彼らが持っていた：
このようなデータベースを装ったスプレッドシートのコレクションでは、CI を完全に避けて、NCI とヒープだけを使用することがますます一般的になっています。明らかに、彼らは CI のパワーや利点をまったく得られませんが、リレーショナル データベースのパワーや利点をまったく得られません。ではありません）。彼らの見方では、とにかく頻繁に「リファクタリング」しなければならないので、わざわざする必要があります。リレーショナル データベースには「リファクタリング」は必要ありません。
この回答についてさらに議論する必要がある場合は、CREATE TABLE/INDEX DDL を投稿してください。そうでなければ、それは時間を浪費する学術的な議論です。
ここに別の（他の回答ですでに提供されていますか？）考えられる理由があります（まだ理解されていません）：
後で更新することを願っていますが、今のところ、これらのトピックをリンクしたいという願望です