私は、会社が開始する新しいデータベースのデータベース標準に取り組んでいます。定義しようとしているものの 1 つは、UniqueIdentifiers に関連する主キーとクラスター化インデックスのルールです。
(注: UniqueIdentifier を主キーまたはクラスター化インデックスとして使用することの長所と短所についての議論は望んでいません。それに関する情報はウェブ上に山ほどあります。これはその議論ではありません。)
だからここに私が心配しているシナリオがあります：
クラスター化インデックスと主キーとして UniqueIdentifier を持つテーブルがあるとします。それをColAと呼びましょう。ColA のデフォルト値を NewSequentialId() に設定しました。
その NewSequentialId() を使用して、3 つの連続した行を挿入します。
{72586AA4-D2C3-440D-A9FE-CC7988DDF065}
{72586AA4-D2C3-440D-A9FE-CC7988DDF066}
{72586AA4-D2C3-440D-A9FE-CC7988DDF067}
次に、サーバーを再起動します。NewSequentialIdのドキュメントには、「Windows を再起動した後、GUID はより低い範囲から再開できますが、依然としてグローバルに一意です」と記載されています。
そのため、次の開始点は前の範囲よりも低くなる可能性があります。
したがって、再起動後、さらに 3 つの値を挿入します。
{35729A0C-F016-4645-ABA9-B098D2003E64}
{35729A0C-F016-4645-ABA9-B098D2003E65}
{35729A0C-F016-4645-ABA9-B098D2003E66}
（GUIDがデータベースでどのように表現されているか正確にはわかりませんが、これは3で始まり、前のものは7で始まっているため、3のものは7のものよりも「小さい」と仮定しましょう。）
クラスター化インデックスの途中で挿入を行う場合、インデックスの再マッピングが発生する必要があります。(少なくとも、私の DBA はそう教えてくれました。) そして、再起動するたびに、新しい UniqueIdentifier 範囲が他の以前の範囲のちょうど真ん中にあるというリスクを冒します。
だから私の質問は次のとおりです: UniqueIdentifiers の次のセットは最後のセットよりも小さいため、すべての挿入によりクラスター化インデックスがシャッフルされますか?
そうでない場合、なぜですか？SQL Server は NewSequentialId を使用していることを認識していますか? それを補う方法はありますか？
そうでない場合、次に何を挿入するかをどのように知るのでしょうか? 次の 100 万回の挿入は 3 から始まるかもしれません。あるいは、7 から始まるかもしれません。
それとも、それを知らず、すべてを整理しているだけですか。その場合、1 回の再起動がパフォーマンスに大きな影響を与える可能性があります。（これにより、再起動の影響を受けない独自のカスタム NewSequentialId が必要だと思います。）それは正しいですか？それとも、私が気付いていない魔法がありますか？
編集:クラスター化されたインデックスとしての GUID は、私の標準では強く推奨されていません。上で述べたように、これが悪い考えである理由はたくさんあります。これが別の理由であるかどうかを調べようとしています。