インデックスをカバーする際に余分な列を特定する方法はありますか? 検索対象とならないため、Includes に抽出されるか、インデックスの適用性に影響を与えずに完全に削除される可能性がある列です。
2 に答える
物事を明確にする カバリング インデックス
の考え方は、検索はできないが (WHERE 句などで使用される)、選択される可能性がある (SELECT 列リストの一部) 列も含まれるということです。
未使用の列がカバリング インデックスに存在することを簡単に確認する方法はないようです。以下の骨の折れるプロセスしか思い浮かびません。
- 代表的な期間、サーバー (または必要なテーブル) で実行されているすべてのクエリを記録します。
- 基になるテーブルを含まないクエリを (正規表現を使用して) 除外する
- 残りのクエリについては、クエリ プランを取得します。問題のインデックスを含まないクエリを破棄する
- 残りのクエリ、またはクエリの各「テンプレート」(多くのクエリは同じですが、検索基準の値)に対して、select または where 句(または JOIN.. .)
- そのリストにないインデックスの列は、問題なく使用できます。
ここで、[削除する列] がさらにいくつかある可能性があります。これは、上記のプロセスでは、カバリング インデックスがどのコンテキストで使用されているかをチェックしないためです (場所を解決するために使用される可能性がありますが、基になるテーブルにはまだアクセスされている可能性があります)。同様に(たとえば、カバーするインデックスにない列にアクセスするには...)
上記の臨床的アプローチは魅力的ではありません。 分析的アプローチが望ましい場合があります。
サーバーを使用するすべてのアプリケーションで使用できるすべてのクエリ「テンプレート」を見つけます。これらの各パターンについて、カバリング インデックスを使用している可能性のあるパターンを見つけます。これらは (ここでもいくつかの穴があります...) 次のようなクエリです。
- 基になるテーブルへの参照を含める
- インデックス内の列ではない基になるテーブルの列を引用しないでください
- インデックスの列よりも選択的な基礎となるテーブルからの検索基準を使用しないでください (非常に順番に...)
または...アプリケーションに行かなくても、すべてのユースケースを考えて、これらのケースに対応するクエリがインデックス内のすべての列からではなくてもメリットがあるかどうかを考えてください。そうすることで、インデックスの最初の数列に関して、インデックスの選択性を比較的よく理解していることになります。
ユースケースとデータポイントの監査を行う場合、使用されていないものや監査で捕捉されていないものは明らかに削除の候補です。データベースがそのような徹底的な監査を欠いている場合は、トレースを実行して保存することで、データベースにヒットするタイム ウィンドウに相当するクエリを節約できます。トレースを分析して、データベースにヒットしているクエリの種類を確認し、そこからどの列を削除できるかを直感的に知ることができます。
トレース分析は通常、欠落しているインデックスの候補を見つけるために使用されますが、使用傾向の分析にも使用できるのではないかと推測しています。