クエリからパフォーマンスの最後の一滴まで絞り込もうとしている場合、これらのタイプのインデックスが結合で使用されると、どのような影響がありますか。
結合に関係する列のみを含み、他には何も含まないクラスター化インデックスを作成した場合、パフォーマンスは向上しますか?
（クラスター化されたインデックスは1つしか持てないため、別のインデックスから移動する（そのインデックスを非クラスター化する）必要があるかもしれません。）
可能であれば、結合のすべての要素と、可能であれば選択しているフィールドを含む非クラスター化インデックスを使用することをお勧めします。
これにより、SQL の実行に必要なすべてのフィールドが 1 つのインデックス上にあることを意味するスパニング インデックスが作成されます。
可能であれば、unnessasery フィールドを含まないインデックスを作成してください。追加されたフィールドごとに個々のインデックス レコードが大きくなり、各インデックス レコードが小さいほど、各ページで取得できる量が多くなります。各ページに取得するインデックス アイテムが多いほど、ディスクに移動する必要が少なくなります。
クラスター化インデックス- テーブルがインデックスで指定された順序で配置されることを意味します。これは、select * from TABLE where INDEXFIELD = 3 のパフォーマンスが向上することを意味します。大量の大きなデータ項目を選択しない限り、これは必要ありません。 .
結合に関係する列のみを含み、他には何も含まないクラスター化インデックスを作成した場合、パフォーマンスは向上しますか?
私が理解しているようではありません。クラスター化インデックスのポイントは、ディスク上のデータをそのインデックスの周りに並べ替えるということです (したがって、1 つしか持てないのはなぜですか)。したがって、結合データがそれらの正確な列によっても並べ替えられていない場合は、違いはあると思います。さらに、(キーではなく) 変更される可能性のあるデータをクラスター化インデックスに入れると、定期的に再構築が必要になる可能性が高くなり、データベース全体の速度が低下します。
くだらない質問で申し訳ありませんが、インデックス チューニング ウィザードを使用してクエリを実行してみましたか? 絶対に確実というわけではありませんが、過去にかなりの改善がありました。