GUID 主キーとしては自然な選択のように思えるかもしれません。本当にそうしなければならない場合は、テーブルの PRIMARY KEY に使用することを主張することもできます。 してはいけないことを強くお勧めします GUID を使用します クラスタリング キーとしての列
2 つの問題を区別する必要があります:
<オール> <リ>
主キー 論理構造 - テーブル内のすべての行を一意かつ確実に識別する候補キーの 1 つです。これは、実際には何でもかまいません - INT 、GUID 、文字列 - シナリオに最も適したものを選択してください。
クラスタリング キー (テーブルの「クラスター化インデックス」を定義する列または列) - これは物理 ストレージ関連のものであり、ここでは、小さくて安定した、増え続けるデータ型が最適です - INT または BIGINT デフォルトのオプションとして。
デフォルトでは、SQL Server テーブルの主キーはクラスタリング キーとしても使用されますが、そうである必要はありません。以前の GUID ベースのプライマリ/クラスター化されたキーを 2 つの個別のキー (GUID のプライマリ (論理) キー) に分割すると、パフォーマンスが大幅に向上するのを個人的に見てきました。 、および別の INT IDENTITY(1,1) のクラスタリング (順序付け) キー 桁。
キンバリー トリップとして
- インデックス作成の女王 - そして他の人が何度も述べている - GUID クラスタリング キーは最適ではないため、そのランダム性により、大量のページとインデックスの断片化が発生し、一般的にパフォーマンスが低下します。
はい、知っています - newsequentialid() があります SQL Server 2005 以降 - しかし、それでさえ完全にシーケンシャルではないため、GUID と同じ問題が発生します。 - 少しだけ目立たなくなりました。
次に、考慮すべき別の問題があります。テーブルのクラスター化キーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されるため、できるだけ小さくする必要があります。通常、INT 大部分のテーブルでは 20 億以上の行で十分なはずです - そして GUID と比較して クラスタリング キーとして使用すると、ディスク上およびサーバー メモリ内に数百メガバイトのストレージを節約できます。
クイック計算 - INT を使用 対 GUID プライマリ キーおよびクラスタリング キーとして:
- 1'000'000 行のベース テーブル (3.8 MB 対 15.26 MB)
- 6 つの非クラスター化インデックス (22.89 MB 対 91.55 MB)
合計:25 MB 対 106 MB - そしてそれは 1 つのテーブルにあるだけです!
もう少し考えてみましょう - Kimberly Tripp の優れたもの - 読んで、もう一度読んで、消化してください!これはまさに、SQL Server のインデックス作成の福音です。
- PRIMARY KEY および/またはクラスター化されたキーとしての GUID
- クラスター化インデックスの議論は続く
- 増加し続けるクラスタリングの鍵 - クラスタ化インデックスの議論....再び!
- ディスク容量は安い - それは ない ポイント!
よほどの理由がない限り 、私は INT IDENTITY を使用することを主張します ほぼすべての「実際の」データ テーブルで、主キーのデフォルトとして - 一意であり、安定しており (決して変化しない)、狭く、常に増加しています - すべての 優れたプロパティ SQL Server テーブルの高速で信頼性の高いパフォーマンスのためにクラスタリング キーに含める必要があります!
これらすべてのプロパティも備えた「自然な」キー値がある場合は、代理キーの代わりにそれを使用することもできます。でも 2 最大の可変長文字列。私の意見では、それぞれ20文字はこれらの要件を満たしていません。