シーケンシャル guid が通常の guid よりも優れたパフォーマンスを発揮する方法を理解しようとしています。
通常のGUIDでは、インデックスがGUIDの最後のバイトを使用してソートするためですか? ランダムなので、新しいデータを挿入するためにデータを別のページに移動することが多いため、多くの断片化とページ分割が発生しますか?
シーケンシャルガイドはシーケンシャルであるため、ページ分割と断片化が大幅に少なくなりますか?
私の理解は正しいですか？
誰かがこの主題にもっと光を当てることができれば、私はとても感謝しています.
ありがとうございました
編集：
順次 GUID = NEWSEQUENTIALID()、
通常の GUID = NEWID()
あなたはあなたの質問でそれをすべて言いました。
シーケンシャル GUID / 主キーを使用すると、テーブルの最後に新しい行がまとめて追加されるため、SQL サーバーにとって便利です。それに比べて、ランダムな主キーは、新しいレコードをテーブルのどこにでも挿入できることを意味します。テーブルの最後のページがキャッシュにある可能性はかなり高いです (すべての読み取りがそこにある場合)。キャッシュ内にあるテーブルの中央にあるランダム ページはかなり少ないため、追加の IO が必要になります。
その上、テーブルの中央に行を挿入すると、余分な行を挿入するのに十分なスペースがない可能性があります。この場合、SQL サーバーは追加の高価な IO 操作を実行して、レコード用のスペースを作成する必要があります。これを回避する唯一の方法は、データ間にギャップを分散させて、余分なレコードを挿入できるようにすることです (データがより多くのページに分散され、テーブル全体にアクセスするにはより多くの IO が必要になるため、それ自体がパフォーマンスの問題を引き起こします。
このトピックに関する Kimberly L. Tripp の知恵に従います。
しかし、シーケンシャルではない GUID - クライアントで生成された値 (.NET を使用) または newid() 関数 (SQL Server で) によって生成された値を持つ GUID は、主に断片化のため、ひどく悪い選択になる可能性があります。ベーステーブルに作成されますが、そのサイズのためにも作成されます。不必要に広いです (int ベースの ID の 4 倍の幅です。これにより、20 億 (実際には 40 億) の一意の行が得られます)。また、20 億以上が必要な場合は、いつでも bigint (8 バイトの int) を使用して 263-1 行を取得できます。