非常に大規模な OLTP データベース (SQL サーバー 2012) を開発しており、GUID を主キーとして使用することを検討しています (クラスター化しないように注意しています)。最初に EF コードを使用しています。
誰かが私たちの決定を手伝ってくれませんか? 記事へのリンクを含めてください。ありがとう
非常に大規模な OLTP データベース (SQL サーバー 2012) を開発しており、GUID を主キーとして使用することを検討しています (クラスター化しないように注意しています)。最初に EF コードを使用しています。
誰かが私たちの決定を手伝ってくれませんか? 記事へのリンクを含めてください。ありがとう
GUID
s は、主キーの自然な選択のように思えるかもしれません。本当に必要な場合は、テーブルの PRIMARY KEY に使用することを主張することもできます。しないことを強くお勧めするのは、GUID
列をclustering keyとして使用することです。特に指定しない限り、SQL Server はデフォルトでこれを行います。
2 つの問題を区別する必要があります。
主キーは論理構造であり、テーブル内のすべての行を一意かつ確実に識別する候補キーの 1 つです。これは、実際には何でもかまいません - INT
、 a GUID
、文字列 - あなたのシナリオにとって最も意味のあるものを選んでください。
クラスタリング キー(テーブルのクラスター化インデックスを定義する列) - これは物理ストレージに関連するものであり、ここでは、小さくて安定した、増え続けるデータ型が最善の選択です -INT
またはBIGINT
デフォルトのオプションとして.
デフォルトでは、SQL Server テーブルの主キーはクラスタリング キーとしても使用されますが、そうである必要はありません。以前の GUID ベースのプライマリ/クラスター化キーを、GUID のプライマリ (論理) キーと別のINT IDENTITY(1,1)
列のクラスター化 (順序付け) キーの 2 つの個別のキーに分割すると、パフォーマンスが大幅に向上することを個人的に見てきました。
インデックス作成の女王であるKimberly Trippや他の人が何度も述べているように、クラスタリング キーとしての GUID は最適ではありません。そのランダム性のために、大量のページとインデックスの断片化が発生し、一般的にパフォーマンスが低下するからです。
はい、私は知っnewsequentialid()
ています-SQL Server 2005以降にあります-しかし、それでも真に完全にシーケンシャルではないため、GUIDと同じ問題に悩まされています-少し目立たないだけです.
次に、考慮すべき別の問題があります。テーブルのクラスター化キーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されるため、できるだけ小さくする必要があります。通常、大多数のテーブルには 20 億以上の行を持つ INT で十分です。クラスタリング キーとしての GUID と比較すると、ディスクとサーバー メモリのストレージを数百メガバイト節約できます。
クイック計算 -INT
対 GUID をプライマリおよびクラスタリング キーとして使用:
合計: 25 MB 対 106 MB - これは 1 つのテーブルでの計算です!
もう少し考えてみましょう - Kimberly Tripp の優れたもの - 読んで、もう一度読んで、消化してください! これは、まさに SQL Server のインデックス作成の福音です。