すべてのプライマリキーがGUIDであるデータベースでは、newid（）とnewsequentialid（）を「デフォルト値またはバインディング」として使用した場合の相違点や賛否両論は何ですか？newid（）とnewsequentialid（）の違いと長所と短所は何ですか？
私が知っている唯一の違いは、newsequential（）はnewsequentialid（）とは対照的に新しいランダムGUIDを作成することです。テーブル内の最後のものに基づいて新しいGUIDをインクリメントして作成します。
私が理解しているように、DBの行に挿入を実行すると、それはテーブル内の他のPKに対して相対的に挿入されます。通常のguidでは、これはテーブルのどこにでも置くことができます。 newsequentialid（）は常にテーブルの末尾に追加されます。
したがって、インサートのパフォーマンスが向上します。
This siteは、2つの異なる方法の違いとベンチマークを説明しています。
更新 - 参照されたブログ投稿が移動されました。このリンクは、web.archive.orgリンクを参照しています。ここで重要なお持ち帰りされています。最も印象的な
はNEWIDシステム機能によって必要とされる書き込みの数です。これは平均ページ密度の69％と相まって、リーフレベルでのインサートのランダムな分布に起因するページ分割の証拠です。ページがいっぱいになるとすぐに、挿入を完了するためにページを50％ずつ2ページに分割する必要があります。ページ分割によってページ密度が低下するだけでなく、データページがかなり壊れています（次のデータページが現在のページの隣にない可能性が99％あります）。私たちのテストでは、ページ分割に必要な空きページの最も多い場所は、行が挿入されている場所に関係なくテーブルの最後にあります。したがって、順番に行を読み取るには、広く分散された分割ページの間でスキャンを前後にジャンプする必要があります。そのため、断片化は厄介です。
--Stefan Delmarco
私が知っているように、NEWID()はランダムな順序でGUIDを生成し、NEWSEQUENTIALID()は順番にGUIDを生成します。 NEWSEQUENTIALID()は、表のデフォルト句でのみ使用できます。
あなたは既に書かれたものに何も追加しませんでした。質問。 –
私の理解から、SQLインスタンスが起動すると、NEWSEQUENTIALID GUIDはランダムな値に初期化されます。その後、操作の間、GUIDは中央のGUIDで増分され、テーブル用に生成された最後のGUIDは表示されません。
これを行う利点は、インデックスにあります。完全なランダムGUIDはインデックスをあまりにも断片化しますが、シーケンシャルGUIDは挿入およびインデックス作成のパフォーマンスに適しています。 – Todd
[Microsoft states]（https://msdn.microsoft.com/da-dk/library/ms189786.aspx）は、ホストマシンが最後に起動されてから最後に生成されたGUIDに関して順次です。 –
（ID、シーケンス、NEWSEQUENTIALIDのような）順次キーと（NEWIDや独自のランダム化されたキージェネレータのような）順不同キーの使用に関して、考慮すべきいくつかの側面があります。
順次キーから始まり、すべての行がインデックスの右端に移動します。ページがいっぱいになると、SQL Serverは新しいページを割り当てて塗りつぶします。この結果、索引の断片化が少なくなり、読取りパフォーマンスには有益です。また、単一のセッションでデータがロードされ、データが単一のドライブまたは少数のドライブに存在する場合、挿入が高速になります。
しかし、多くのスピンドルを持つハイエンドのストレージサブシステムでは、状況が異なる可能性があります。複数のセッションからデータをロードすると、ページ・ラッチの競合（ラッチはデータベース・ページへのアクセスを同期するために使用されるオブジェクトです）が、インデックス・リーフ・レベルのリンク・リストの右端のページで終了します。このボトルネックは、ストレージ・サブシステムのフル・スループットの使用を防ぎます。 シーケンシャルキーを使用して数値キーを使用する場合は、常に範囲内の最小値で開始して、範囲全体を使用することができます。たとえば、INT型で1で始まるのではなく、-2,147,483,648で始めることができます。
NEWIDで生成されたランダムなキーやカスタムソリューションなど、非順次的なキーを検討してください。既にフルページに行を強制しようとすると、SQL Serverは従来のページ分割を実行します。新しいページが割り当てられ、元のページの半分が新しいページに移動されます。ページ分割にはコストがかかり、インデックスの断片化が発生します。索引の断片化は、読取りのパフォーマンスに悪影響を及ぼす可能性があります。ただし、挿入パフォーマンスに関して、ストレージサブシステムに多数のスピンドルが含まれていて、複数のセッションからデータをロードしている場合、スプリットにもかかわらず、ランダム順序は実際にはシーケンシャルよりも優れています。
インデックスの右端にホットスポットがなく、ストレージサブシステムの のスループットを向上させるためです。この戦略を示すベンチマークの良い例は、Thomas Kejserのブログ、http://blog.kejser.org/2011/10/05/boosting-insert-speed-by-generating-scalable-keys/にあります。
出典： クエリのMicrosoft® SQLServer®の2012 試験70から461 トレーニングキット
えっ？それらが連続して生成される場合、GUIDのようなものではなく、生成されたGUIDが実際にユニークであることをguarneteedにすることができますか？ – Justin
@Justing - GUIDが一意であるという保証はありません。 –
リンクは揮発性です... Fotia now 404sは答えのリンクです。 –