[解決済み] クラスタ化インデックスと非クラスタ化インデックスの違い[重複]について

質問

を追加する必要があります。 index を追加する必要があり、いくつかの助けを必要としています。

私は混乱しており、いくつかの点を明確にする必要があります。

• にインデックスを使用すべきでしょうか。 non-int カラムにインデックスを使うべきでしょうか？なぜ/なぜそうしないか

• についてたくさん読みました。 clustered と non-clustered の2つのインデックスがありますが、いつどちらを使うかまだ決めかねています。良い例があれば、私や他の多くの開発者の助けになります。

頻繁に更新されるカラムやテーブルにはインデックスを使用すべきではないことは知っています。また、テスト段階に進む前に、それがすべて良好であることをどのように知ることができますか？

どのように解決するのですか?

2つの問題を分離する必要があります。

1)は 主キー は論理的な構成で、テーブルのすべての行を一意的かつ確実に識別するキーの候補のひとつです。これは、INT、GUID、文字列など、本当に何でもかまいません。

2) クラスタリングキー (テーブル上の "クラスタ化インデックス" を定義するカラム) - これは 物理的 ストレージに関連するもので、ここでは、小さくて安定した、増え続けるデータ型が最適な選択です。

デフォルトでは、SQL Serverテーブルの主キーはクラスタリングキーとしても使用されますが、そのようにする必要はありません!

すべてのテーブル (データを格納するために使用するテーブル、ルックアップ テーブルなど) はクラスタリング キーを持つ必要があります。クラスタリング・キーがないのは意味がない。実際、一般的に信じられていることとは異なり、クラスタリングキーを持つことで、挿入や削除を含むすべての一般的な操作が高速化されます（テーブルの構成が異なるため、通常は ヒープ - を使用する場合よりも優れています)。

インデックス作成の女王、Kimberly Tripp には、なぜクラスタリングキーを持つべきなのか、そしてどのようなカラムをクラスタリングキーとして使用するのが最適なのかというトピックについて、非常に多くの優れた記事があります。1つのテーブルに1つしかないため、クラスタリングキーに最適なカラムを選ぶことが最も重要です。 正しい クラスタリングキーを選ぶことが最も重要です。

• PRIMARY KEY および/またはクラスタ化されたキーとしての GUID
• クラスター化インデックスの議論は続く
• 増え続けるクラスタリングキー - クラスタ化インデックス論争.........再び!
• ディスクスペースは安い - それは ではない がポイントです。

マルク