8

私は SQL サーバーのパフォーマンスにかなり精通していますが、クラスター化された主キーの既定の型として GUID を使用する必要があるという考えについては、常に反論しなければなりません。

テーブルの 1 日あたりの挿入数がかなり少ない (5000 +/- 行 / 日) と仮定すると、どのような種類のパフォーマンスの問題が発生する可能性がありますか? ページ分割はシークのパフォーマンスにどのように影響しますか? どのくらいの頻度でインデックスを再作成 (またはデフラグ) する必要がありますか? フィル ファクタを (100、90、80 など) に設定する必要がありますか?

1 日あたり 1,000,000 行を挿入するとどうなるでしょうか。

すべての質問について事前に謝罪しますが、PK のデフォルトとして GUID を使用しないためのバックアップを探しています。しかし、私は、StackOverflow ユーザーベースからの圧倒的な知識によって私の考えが変わることに対して完全にオープンです。

4

4 に答える 4

8

あらゆる種類のボリュームを実行している場合、説明した正確な理由により、シーケンシャル GUIDを使用しない限り、GUID は PK として非常に悪いです。ページの断片化が深刻です:

                 Average                    Average
                 Fragmentation  Fragment    Fragment   Page     Average 
Type             in Percent     Count       Size       Count    Space Used

id               4.35           7           16.43      115      99.89
newidguid        98.77          162         1          162      70.90 
newsequentualid  4.35           7           16.43      115      99.89

そして、このGUID と整数の比較が示すように:

Test1 では大量のページ分割が発生し、挿入が完了した後に DBCC SHOWCONTIG を実行したときのスキャン密度は約12%でした。Test2 テーブルのスキャン密度は約 98% でした

ただし、音量が非常に小さい場合は、それほど重要ではありません。

グローバルに一意の ID が本当に必要であるが、量が多い (そして連続した ID を使用できない) 場合は、GUID をインデックス付きの列に入れます。

于 2009-09-24T04:00:50.980 に答える
2

GUID を主キーとして使用することの欠点:

  • 意味のある順序付けはありません。つまり、インデックスを作成しても、整数の場合のようにパフォーマンスが向上しません。
  • GUID のサイズは 16 バイトですが、整数の場合は 2、4、または 8 バイトです。
  • 人間が覚えるのは非常に難しいため、参照 ID としては適していません。

利点:

  • Web ページのクエリ文字列またはアプリケーションで表示される場合に危険性が低くなる可能性がある、推測不可能な主キーを許可します。
  • 自動インクリメントまたは ID データ型を提供しないデータベースで役立ちます。
  • プラットフォームや環境を越えて、2 つの異なるデータ ソース間でデータを結合する必要がある場合に便利です。

GUID を使用するかどうかの決定は非常に簡単だと思いましたが、他の問題を認識していない可能性があります。

于 2009-09-24T03:58:34.203 に答える
1

1 日あたりの挿入数が非常に少ないため、ページ分割が重要な要因であるとは思えません。本当の問題は、5,000 が既存の行数とどのように比較されるかということです。これは、分割を延期するための適切な初期 FILL FACTOR を決定するために必要な主な情報になるからです。

つまり、私は個人的に GUID の大ファンではありません。状況によってはうまく機能することは理解していますが、多くの場合、[効率性、使いやすさ、...] の「邪魔」にすぎません。

次の質問は、GUID を使用するかどうかを決定する際に絞り込むのに役立ちます。

  • PK は共有/公開されますか? (つまり、SQL 内での内部使用を超えて使用されますか? アプリケーションはこれらのキーをある程度永続的な方法で必要としますか? ユーザーはこれらのキーを何らかの方法で見ることができますか?
  • PK を使用して、異種のデータ ソースをマージできますか?
  • テーブルには、データ内の列から作成されたプライマリ (場合によっては複合) がありますか? この可能性のあるこのキーのサイズは?
  • 主キーはどのようにソートされますか? 複合の場合、最初の数列は選択的ですか?
于 2009-09-24T04:00:45.380 に答える
0

クラスター化インデックスとして GUID (シーケンシャル GUID でない限り) を使用すると、挿入のパフォーマンスが低下します。物理的なテーブル レイアウトはクラスター化されたインデックスに従って配置されるため、ランダムなシーケンス順序を持つ GUID を使用すると、深刻なテーブルの断片化が発生します。GUID を PK/クラスター化インデックスとして使用する場合は、SQL サーバーで newsequentialid() 関数を使用するシーケンシャル GUID である必要があります。これにより、生成された GUID が順番に並べられ、断片化が防止されることが保証されます。

于 2009-09-24T04:05:55.313 に答える