複数のテーブルで結合を実行するクエリがあります。テーブルの外部キーに非クラスター化インデックスがあり、主キーにクラスター化インデックスがあります。クエリ プランを分析したところ、クエリ オプティマイザーがすべてのテーブルでクラスター化インデックス スキャンを選択しているか、非クラスター化インデックス スキャンとキー ルックアップを組み合わせて他の非キー列をフェッチしていることがわかりました。これを修正するために、このクエリで必要な非キー列を非クラスター化インデックスに含めました (カバーしました)。この結果、非クラスター化インデックスのシーク/スキャンが期待どおりに実行されていることがわかりました。
私の質問は、他の多くの非キー列を結果セットの一部にする必要がある他のクエリがある場合、すべての列を非クラスター化インデックスに追加 (INCLUDING) して、すべてのクエリのパフォーマンスを向上させる可能性があることです。 . これは良い考えでしょうか？
ありがとう。
あなたの使い方を理解するのは非常に重要です。クエリを実行できる可能性のあるすべてのものにインデックスを追加するのは非常に簡単ですが、すべての場合と同様にトレードオフです。すべてのインデックスは時間とストレージのコストがかかるため、挿入/更新が遅くなる可能性が高く、インデックスを作成すればするほど、このコストが高くなります。
使用量が書き込みよりも読み取りを優先する場合は、すべて問題なく、ストレージの料金を支払うだけで済みます。書き込みにもまともなパフォーマンスが必要な場合は、実際にできることは、アプリケーションを理解し、最も重要なものにインデックスを付けることだけです.
「inside sql server」シリーズの本 (Kalen Delaney et al) を強くお勧めします。読み通すには多くの本を読む必要がありますが、これらの本があなたが行っているトレードオフを理解するのに役立つことを保証します。
WHERE 句で必要な列を含めたようで、結果としてインデックス シークが発生しました。
SELECT リストにある列を含めることもできます。これにより、別の利点が得られます。SELECT リストを含め、クエリで必要なすべてのフィールドがインデックスに含まれている場合、クエリ結果はインデックスから直接返すことができ、テーブル レコードに戻る必要はまったくありません。
もちろん、UPDATE、INSERT、および DELETE 操作には、インデックス構築の追加コストが含まれます。
SQL Server Management Studio Tools > SQL Server Profiler を実行して、現在のデータベース アクティビティのサンプルを取得できます。次に、これを [ツール] > [データベース エンジン チューニング アドバイザー] にフィードできます。INSERT および UPDATE アクティビティが多い場合、チューニング アドバイザーはいくつかのインデックスの削除を提案する場合があります。アクティビティが主に SELECT ステートメントである場合は、追加のインデックスが提案される可能性があります。
データベース エンジン チューニング アドバイザーは、あなたが説明したように、多くの列にわたってインデックスをカバーすることを提案することがよくあります。この件に関しては、その提案に従うこともありますが、特定のクエリに特定のパフォーマンスの問題がない限り、インデックス作成をキー列と条件列に制限することがよくあります。