これはインデックスであるため、すべての場合において非 null で一意であることが保証されている列 (または列のセット) を選択する必要があります。これが最大かつ最も厳しい基準です。NULL または重複する可能性があるものは、最初から問題外です。
このインデックス付きビューで実行するクエリの種類によっては、範囲クエリを実行する列 (DATE など) があるかどうかを確認することもできます。これは、クラスタリング キーの興味深い候補になる可能性があります。
ただし、重要なことは、どのような状況でも、クラスタリング キーは一意で、null でない必要があるということです。私の個人的な経験では、インデックスのサイズを小さくする (したがって、ページあたりのエントリ数を増やす) ために、できるだけ小さなキーを使用するようにします。1 つの INT が最適か、2 つの INT の組み合わせが最適です。 GUID - ただし、クラスタリング キーで VARCHAR(500) フィールドを使用しないでください。
更新: クラスタ化されたインデックスは一意である必要はないと私たちに言い続けているすべての投稿者へ - 「インデックス作成の女王」である Kimberly Tripp がこのトピックについて何を言わなければならないかをチェックしてください:
クラスタリング キーで探す主なものから始めましょう。
* Unique
* Narrow
* Static
なぜユニークなのですか?
クラスタリング キー (存在する場合) はすべての非クラスタ化インデックスからの検索キーとして使用されるため、クラスタリング キーは一意である必要があります。本の後ろにある索引を例にとると、索引エントリが指すデータを見つける必要がある場合、そのエントリ (索引エントリ) は一意でなければなりません。 ? したがって、クラスター化インデックスを作成するときは、一意である必要があります。ただし、SQL Server では、一意の列でクラスタリング キーを作成する必要はありません。任意の列に作成できます。内部的には、クラスタリング キーが一意でない場合、SQL Server はデータに 4 バイトの整数を追加することでそれを "一意化" します。そのため、クラスター化インデックスが一意ではないものに作成された場合、インデックス作成時に追加のオーバーヘッドが発生するだけでなく、ディスク領域が無駄になり、INSERT と UPDATE に追加のコストが発生し、SQL Server 2000 ではクラスター化されたインデックスに追加のコストが発生します。再構築します (これは、クラスタリング キーの選択が不適切なため、より可能性が高くなります)。
ソース: http://www.sqlskills.com/blogs/kimberly/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx