次のような状況があります: ローカルで動作するデータベースを作成していますが、同じスキーマを持ち、既にいくつかのデータを持っているオンライン データベースに移行できます。このため、ID を使用した場合に発生する主キーの値を変更する (およびそれを参照テーブルにカスケードする) 必要がなくなるため、移行が容易になるため、テーブルの主キーとして GUID を使用する予定です。コラム（そうですか？）。データベースは SQL Server 2012 上に構築されています。
それにもかかわらず、データベース テーブルでのクエリを高速化するためにクラスター化インデックスを作成したいと考えています。多くの記事やスタック オーバーフローの回答を読んで、GUID プライマリ キーにクラスター化インデックスを作成するのは得策ではないと確信しています。 . 問題は、このデータベース テーブルにクラスター化インデックスを作成するための適切な解決策があるかどうかです。GUID を削除して、別のデータ型を追加することにオープンです。一瞬、HiLo アプローチを使用することを考えましたが、移行が難しくなると思います。これはオプションですが、それを選択するには本当に正当な理由が必要です (つまり、GUID を使用する良い方法がない場合)。広告 PK とクエリの高速化)。
今まで私はこれらの解決策を考えていました：
- newsequentialid() を使用して新しい GUID を生成し、それらをシーケンシャルにし、クラスター化インデックスとしてより適切にします。ここでの質問は次のとおりです。これは本当に int 主キーを使用するよりも優れているのでしょうか? ここで GUID を使用する主な理由は、最終的に発生する移行を支援することです。これらを順次にすると、ここでは役に立たないと思います。さらに、クライアント側で作成するのではなく、データベースで生成された GUID を取得する必要があります。
- COMB GUIDを使用し、それをクラスター化インデックスにもします。高い「乱数係数」を維持しながら、以前のアプローチに存在するいくつかの問題を解決しているようですが、結果があるかどうかはわかりません。ある？
- ID int 列を追加し、それをクラスター化インデックスとして使用します。ここでの私の質問は、GUID である PK 値を使用してクエリが作成されるため、何かに役立つかどうかです。
- ID int を主キー値とクラスター化インデックスに変換し、クエリを作成するために使用する GUID 列を追加するという、前のアプローチを少し変更します。Adventure Works 2012 ではこれが選択であることがわかりますが、それがどこで役立つかはよくわかりません... PK でもクラスター化でもない GUID で値をクエリすると、クラスター化インデックスが役立ちますか?
私が思いつくことができるのはそれだけだと思います.COMBアプローチを選択する傾向があり、それが優れているかどうか、およびその理由を検証するためにいくつかの実験を考えています. しかし、このシナリオでより良い解決策はありますか?