私のチームがアプリケーションに使用しているデータベースのパフォーマンスを最適化したいと考えています。
外部キーを追加する領域を探しており、それらの列にインデックスを付けて結合のパフォーマンスを向上させています。ただし、テーブルの多くはGUID、アイテムの挿入時に生成される型である ID で結合されており、他のテーブルのそのアイテムに関連付けられているデータには通常item_id、GUID を含む列があります。
GUID 型の列にクラスター化インデックスを追加することは非常に悪い決定であると読んだことがあります。これは、有効にするためにインデックスを常に再構築する必要があるためです。しかし、上記のシナリオで非クラスター化インデックスを使用することに何か不利益があるのでしょうか? それとも、それがパフォーマンスに役立つと仮定するのは合理的ですか? 必要に応じて、さらに情報を提供できます。
aのインデックスは、<anytype>結合とシングルトンルックアップを改善するために必要な最善のオプションです。このインデックスがないと、クエリは常にテーブル全体をエンドツーエンドでスキャンする必要があり、（多くの場合）パフォーマンスの結果がひどくなり、同時実行性が低下します。
あなたが言及した理由のためにインデックスの選択が不適切であることは事実ですが、決してこれらのインデックスを作成すべきではないuniqueidentifierことを意味するわけではありません。可能であれば、データ型をINTまたはBIGINTに変更することをお勧めします。またはを使用してそれらを生成すると、断片化の問題に役立ちます。すべての選択肢が失敗した場合、他のインデックスよりも頻繁にインデックスのメンテナンス（再構築、再編成）操作を実行する必要があります。しかし、これらの欠点のいずれも、そもそもインデックスを持つことの利点を上回ることは決してありません！NEWSEQUENTIALID()UuidCreateSequential
2 つのパフォーマンス:
- 挿入
- 選択
インデックスは選択を改善する必要があります
インデックスは挿入を遅くします。
挿入が順番に行われている場合、インデックスはフラグメント化されません。
挿入が適切でない場合、インデックスはフラグメント化されます。
インデックスの断片化は、挿入と選択の両方を遅くします。
メンテナンスを介して、インデックスを最適化できます。
FK を参照する列に非クラスター化インデックスを追加すると、結合に役立ちます。
その列は順序付けられていない可能性が最も高いため、GUID であることは失われません。
FK テーブル自体では、GUID は PK (クラスター化インデックス) の候補として適切ではありません。
挿入時にフラグメントにインデックスを付ける PK として GUID を使用します。
Int またはシーケンシャル ID は、挿入時に PK をフラグメント化しないため、より適切な候補です。
しかし、これらのテーブルを最適化するだけで大したことはありません。
はい、Guid インデックスをクラスター化から非クラスター化に変更することをお勧めします。Guid は引き続き主キーにすることができ、クエリ/ソース コードを変更する必要はありません。データの並べ替えが不要で、パフォーマンスが向上します。
SQL Azure のようなデータベースでは、クラスター化されたインデックスを持つことが必須です。したがって、日付/日時フィールドを使用できます。あるチームの一部の開発者は、これらの GUID と他の GUID を使用する傾向があるため、追加の int-identity/autoincrement 列を作成する必要はありません。一貫性のないアプリケーションが発生します。したがって、GUID のみを保持してください。
シーケンシャル Guid について言えば、Guid はデータベースから作成するよりもコードから作成するほうがよいと思います。最新の DAL とリポジトリ パターンは、CRUD の DB への依存を好まない。例: linq クエリと、DB に依存しない単体テストを使用した自動ビルド。また、シーケンシャル GUID を自分で作成することはお勧めできません (少なくとも私にとっては)。したがって、クラスター化されていないインデックスを持つ主キーとしての Guid が最適なオプションです。
クラスター化されていない件名についてマイクロソフトから支援を受けていますhttp://blogs.msdn.com/b/sqlazure/archive/2010/05/05/10007304.aspx
編集済み：バッキングがなくなりました（「リソースが見つかりません」）
通常、パフォーマンスに役立ちます。しかし、避けられないページ分割がそれほど頻繁に発生する必要がないように、fillfactor が 100% 未満のインデックスを作成したい場合があります。インデックスの定期的なメンテナンスは確かにプラスになります。
はい、あなたの状況には非クラスター化インデックスが理想的です。基になるものはクラスター化インデックスのような B ツリーですが、テーブルの基になるデータは並べ替えられていないため、GUID の非連続性の問題は存在しません。NC インデックスは、テーブルとは別に存在します。
ただし、クラスター化されていないインデックスを追加しすぎないように注意してください。必要な場所だけを最適化します。プロファイラーを実行して、どのクエリに時間がかかっているかを確認し、それらのみを最適化します。さらに、データベースがめったに更新されない場合やスペースに制約がある場合を除き、FILL FACTOR の値を 50% 未満に設定してください。
関連する MSDN: http://msdn.microsoft.com/en-us/library/ms177484(v=sql.105).aspx