Foo テーブルに、 ColA とColB に非クラスター化インデックスがあり、ColC、ColD にインデックスがないことを想像してください。
SELECT colA, colB
FROM Foo
約 30 秒かかります。
SELECT colA, colB, colC, colD
FROM Foo
約 2 分かかります。
Foo テーブルには 500 万行以上あります。
質問: インデックスの一部ではない列を含めると、クエリが遅くなる可能性はありますか? はいの場合、なぜですか? -既に読まれたページの一部ではありませんか?
カバリング インデックスを使用するクエリを作成すると、ヒープ/クラスター化インデックス内の完全なデータ ページにはアクセスされません。
その後、クエリにさらに列を追加して、インデックスがカバーしなくなった場合、追加のルックアップが発生するか (インデックスがまだ使用されている場合)、別のデータ アクセス パス全体を強制します (テーブル スキャンを使用するなど)。インデックスを使用する代わりに)
2005 年以降、SQL Server はインデックスに含まれる列の概念をサポートしています。これには、インデックスのリーフにある非キー列が含まれます。そのため、インデックス使用のデータ ルックアップ フェーズでは役に立ちませんが、ヒープ/クラスター化インデックスで追加のルックアップを実行しないようにするのに役立ちます。インデックスをカバリングインデックスにするのに十分です。
また、将来、あるクエリが高速で別のクエリが遅い理由をよりよく理解したい場合は、実行プランの生成を検討してください。これを比較できます。
使用されている用語を理解していなくても、少なくともそれらの「違いを見つける」ことができ、用語を検索できるはずです (テーブル スキャン、インデックス シーク、ルックアップなど)。
簡単な答えは次のとおりです。非クラスター化インデックスはデータと同じページに格納されないため、SQL Server は実際のデータ ページを参照して残りを取得する必要があります。
非クラスター化インデックスは別のデータ構造に格納されますが、クラスター化インデックスは実際のデータと同じ場所に格納されます。そのため、クラスター化インデックスは 1 つしか持てません。