GUID パフォーマンス

GUID s は、主キーの自然な選択のように思えるかもしれません。本当に必要な場合は、テーブルの PRIMARY KEY に使用することを主張することもできます。 してはいけないことを強くお勧めします GUID を使用します クラスタリングキーとしての列

2 つの問題を区別する必要があります:

<オール> <リ>

主キー 論理構造 - テーブル内のすべての行を一意かつ確実に識別する候補キーの 1 つです。これは、実際には何でもかまいません - INT 、GUID 、文字列 - シナリオに最も適したものを選択してください。

<リ>

クラスタリングキー (クラスタ化インデックスを定義する 1 つまたは複数の列テーブルの上) - これは物理的な ストレージ関連のものであり、ここでは、小さくて安定した、増え続けるデータ型が最適です - INT または BIGINT デフォルトのオプションとして。

デフォルトでは、SQL Server テーブルの主キーはクラスタリングキーとしても使用されますが、そうである必要はありません。以前の GUID ベースのプライマリ/クラスタ化キーを 2 つの個別のキー (GUID のプライマリ (論理) キーと個別の INT IDENTITY(1,1) 桁。

キンバリートリップとして - インデックス作成の女王 - および他の人が何度も述べています - クラスタリングキーとしての GUID は最適ではありません。そのランダム性のために、大量のページとインデックスの断片化が発生し、一般的にパフォーマンスが低下するからです。

はい、知っています - newsequentialid() があります

次に、考慮すべき別の問題があります。テーブルのクラスター化キーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されるため、できるだけ小さくする必要があります。通常、大多数のテーブルには 20 億以上の行を持つ INT で十分です。クラスタリングキーとしての GUID と比較すると、ディスクとサーバーメモリのストレージを数百メガバイト節約できます。

クイック計算 - INT を使用 vs. プライマリおよびクラスタリングキーとしての 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 のインデックス作成の福音です。