クラスタ化インデックスは、実際のデータ行をインデックスのリーフ レベルに格納します。上記の例に戻ると、主キー値 123 に関連付けられたデータ行全体がそのリーフ ノードに格納されることになります。
質問- 主キーが存在せず、Name
列をクラスター化インデックスとして設定した場合。この場合、上記のステートメントは矛盾しますか?
クラスタ化インデックスは、実際のデータ行をインデックスのリーフ レベルに格納します。上記の例に戻ると、主キー値 123 に関連付けられたデータ行全体がそのリーフ ノードに格納されることになります。
質問- 主キーが存在せず、Name
列をクラスター化インデックスとして設定した場合。この場合、上記のステートメントは矛盾しますか?
いいえ - なぜですか?
クラスター化インデックスは、(最初は) 列によって物理的に並べ替えられたリーフ レベルで実際のデータ ページを格納しますname
。
リーフ レベルより上のインデックス ナビゲーション構造には、name
すべての行の列値が含まれます。
全体として、何も変わりません。
主キーは、テーブル内の各行を一意に識別するように設計された論理構造です。そのため、一意で null でない必要があります。
クラスタリング インデックスは、(最初に) クラスタリング キーによってデータを物理的に並べ替え、それに応じて SQL Server ページを配置する物理構造です。
SQL Server では、既定でプライマリがクラスタリング キーとして使用されますが、この 2 つが一緒になる必要はなく、一方が他方と一緒に存在する必要もありません。クラスター化されていない主キーを持つテーブル、または主キーのないクラスター化されたテーブルを持つことができます。どちらも可能です。それが賢明かどうかは別の議論ですが、技術的には可能です。
更新:主キーがクラスタリング キーである場合、一意性が保証されます (主キーは一意である必要があるため)。プライマリ キーではない列をクラスタリング キーとして選択し、その列が一意性を保証しない場合、SQL Server は - バックグラウンドで - それらの重複値に 4 バイト (INT) 一意化子列を追加して作成します。それらはユニークです。そのため、Smith のクラスター化インデックス ナビゲーション構造に、Smith
などがある場合があります。Smith1
Smith2
見る:
クラスター化インデックスが一意でない場合、SQL Server は 4 バイトの一意識別子を作成し、それをクラスター化インデックス値に追加します。一意化子は、すべてのクラスター化インデックス値ではなく、クラスター化インデックス値が重複している場合にのみ追加されます。すべての非クラスター化インデックスには、リーフ レベルにこの値が含まれます。一意でない非クラスター化インデックスの非リーフ レベル エントリには、ブックマークの一部として、この固有値も含まれます。
主キーと一意のインデックス(または制約)の違いは、主キー列にNull値を使用できないことです。テーブルに主キーを設定する必要はありませんが、外部アプリケーションがテーブルの行を編集しやすくなります。それでも、ほとんどの外部アプリケーションでは必要ありません。
パフォーマンスに関しては、これは何も変わりません。重要なのはインデックスの有無(一意かどうか、クラスター化されているかどうか、null値があるかどうか)であり、主キーは基本的にnull値のないもう1つの一意のインデックスです。
クラスタ化インデックスの場合、列は一意である必要はなく、nullがない必要もありません。重複してnull値を持つ列は、クラスター化インデックスを作成するのに適しています。
外部キーの場合、一意のインデックスを持つ列を参照する必要がありますが、必ずしも主キーまたはnull値がない列を参照する必要はありません。主キーではなく、一意のインデックスがある限りnull値を許可している列を参照することは完全に合法です。一意のインデックスが必要なため、この列に複数のnull値を含めることはできないことに注意してください。
外部キー列自体(外部テーブルの列)に制限はありませんが、パフォーマンスの観点から、インデックスを設定することはしばしば良いことです。