GUIDはランダム性が高いため、クラスター化されたキーとして問題があります。この問題は、前回のTechnet MagazineのQ＆AコラムでPaul Randalによって対処されました。クラスター化されたインデックスキーとしてGUIDを使用したいのですが、他の人は、インデックスのパフォーマンスの問題につながる可能性があると主張しています。これは本当ですか？もしそうなら、その理由を説明できますか？
ここで、議論は特にクラスター化に関するものであることを覚えておいてください。 インデックス。列を「ID」として使用したいとしますが、それがクラスター化されたキーなのか、単に主キーなのかは不明です。通常、この2つは重複しているため、クラスター化されたインデックスとして使用することを想定します。それが不適切な選択である理由は、上記の記事へのリンクで説明されています。
非クラスター化インデックスの場合、GUIDにはまだいくつかの問題がありますが、テーブルの左端のクラスター化キーである場合ほど大きくはありません。繰り返しになりますが、GUIDのランダム性により、非クラスター化インデックスレベルのみであるかどうかにかかわらず、ページの分割と断片化が発生します（はるかに小さな問題）。
GUIDの使用法を取り巻く多くの都市伝説があり、int（4バイト）と比較してサイズ（16バイト）に基づいて非難し、使用すると恐ろしいパフォーマンスの運命を約束します。これは少し誇張されています。サイズ16のキーは、適切に設計されたデータモデルでは、依然として非常にパフォーマンスの高いキーになる可能性があります。確かに、intの4倍の大きさになると、密度の低い非リーフページが増えます。 インデックスでは、これは大多数のテーブルにとって実際の問題ではありません。 Bツリー構造は、自然にバランスの取れたツリーであり、深さ ツリートラバーサルの問題が発生することはめったにないため、INTキーではなくGUIDキーに基づいて値を探すことは、パフォーマンスが似ています。リーフページトラバーサル（つまり、テーブルスキャン）は非リーフページを調べません。レコード自体が導入された追加の12バイトよりも大幅に大きいため、GUIDサイズがページサイズに与える影響は通常非常に小さくなります。 GUIDによる。だから私は、「16バイト対4」に基づいたヒアリングアドバイスを、かなり大きな塩の粒で受けます。個々のケースバイケースで分析し、サイズの影響が実際に違いを生むかどうかを判断します。その他の数 テーブル内の列（つまり、リーフページのGUIDサイズにどの程度の影響があるか）と、それを使用している参照の数（つまり、その他の数） より大きな外部キーを格納する必要があるため、テーブルは増加します。
GUIDは最近多くの悪い報道を受けており、一部はそれに値しないため、私はGUIDのある種の間に合わせの防御でこれらすべての詳細を呼び出しています。それらにはメリットがあり、あらゆる分散システムに不可欠です（データの移動について話している瞬間、レプリケーションや同期フレームワークなどを介して）。適切な考慮なしに回避されたときに、GUIDの悪い評判に基づいて悪い決定が下されるのを見てきました。ただし、クラスター化されたキーとしてGUIDを使用する必要がある場合は、ランダム性の問題に対処するようにしてください。シーケンシャルGUIDを使用してください 可能な場合。
そして最後に、あなたの質問に答えるために：あなたが特定のを持っていない場合 GUIDを使用する理由は、INTを使用してください。