シナリオの簡単な概要:
私のデータベースは GUID を主キーとして使用しており、私が読んでいる限り、GUID にクラスター化されたインデックスを使用するのはやや悪いようです (断片化が増加し、挿入が遅くなるなど)。私のプロジェクトは休止状態を使用しているため、通常は jpql と完全なエンティティのフェッチを処理します (多くのクエリが最終的に に変わりますselect p.* from person p [...])
テーブルのすべての列をカバーする非クラスター化インデックスを作成するのが良い方法であるかどうかを知りたいです (RID ルックアップなどを避けるため)。
助けてくれてありがとう、すでに！
いいえ、それは良い方法ではありません。GUID にクラスター化インデックスを設定するのは良くないということを既にお読みになっているようです。代わりに、int (または必要に応じて bigint) の ID フィールドを作成し、それをクラスター化インデックスにします。次に、GUID フィールドに非クラスター化インデックスを作成し、それを使用するクエリごとに SQL に RID ルックアップを実行させます。このようにして、断片化と遅い挿入/更新/削除を回避できます。
時期尚早の最適化は悪い考えです。挿入、更新、および削除に追加されるデータ サイズのコストと労力は、インデックスを追加する価値がありますか? パフォーマンスとインデックスの影響を測定してテストしない限り、それはわかりません。テーブルを読み取るクエリを調べて、容認できないほど長いクエリがあるかどうかを確認します。次に、その特定のクエリを調整します。