0

非常に大規模な OLTP データベース (SQL サーバー 2012) を開発しており、GUID を主キーとして使用することを検討しています (クラスター化しないように注意しています)。最初に EF コードを使用しています。

誰かが私たちの決定を手伝ってくれませんか? 記事へのリンクを含めてください。ありがとう

4

1 に答える 1

4

GUIDs は、主キーの自然な選択のように思えるかもしれません。本当に必要な場合は、テーブルの PRIMARY KEY に使用することを主張することもできます。しないことを強くお勧めするのは、GUID列をclustering keyとして使用することです。特に指定しない限り、SQL Server はデフォルトでこれを行います。

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

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

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

デフォルトでは、SQL Server テーブルの主キーはクラスタリング キーとしても使用されますが、そうである必要はありません。以前の GUID ベースのプライマリ/クラスター化キーを、GUID のプライマリ (論理) キーと別のINT IDENTITY(1,1)列のクラスター化 (順序付け) キーの 2 つの個別のキーに分割すると、パフォーマンスが大幅に向上することを個人的に見てきました。

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

はい、私は知っnewsequentialid()ています-SQL Server 2005以降にあります-しかし、それでも真に完全にシーケンシャルではないため、GUIDと同じ問題に悩まされています-少し目立たないだけです.

次に、考慮すべき別の問題があります。テーブルのクラスター化キーは、テーブルのすべての非クラスター化インデックスのすべてのエントリにも追加されるため、できるだけ小さくする必要があります。通常、大多数のテーブルには 20 億以上の行を持つ INT で十分です。クラスタリング キーとしての 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 のインデックス作成の福音です。

于 2013-02-21T06:43:09.227 に答える