カバリングインデックス内の不要な列を特定する方法は何ですか?

Question

カバリングインデックス内の余分な列を識別するにはどのような方法がありますか:決して検索されないため、インデックスの適用性に影響を与えることなく、インクルードに抽出されたり、完全に削除されたりする可能性がある列はありますか?

Answer 1

物事を明確にする
という考え カバリングインデックス つまり、検索はできないが (WHERE 句などで使用)、選択できる (SELECT 列リストの一部) 列も含まれています。

カバーインデックスに未使用の列が存在することを確認する簡単な方法はないようです. 。私が思いつくのは、次のような骨の折れるプロセスだけです。

• 代表的な期間において、サーバー (または必要なテーブル) で実行されているすべてのクエリを記録します。
• 基になるテーブルに関係しないクエリを (正規表現によって) フィルタリングして除外します。
• 残りのクエリについては、クエリ プランを取得します。問題のインデックスを含まないクエリを破棄します。
• 残りのクエリ、またはクエリの「テンプレート」ごとに (多くのクエリは、検索条件の値が異なるだけで同じです)、select 句または where 句 (または JOIN..) にあるインデックスから列のリストを作成します。 。）
• そのリスト内に見つからないインデックスの列は問題なく使用できます。

上記のプロセスでは、カバーするインデックスがどのコンテキストで使用されているかをチェックしないため、[削除する列] がさらにいくつかある可能性があります (where を解決するために使用される可能性はありますが、基になるテーブルは引き続きアクセスされます)同様に (たとえば、カバーインデックスにない列にアクセスする場合など)

上記の臨床アプローチはかなり魅力的ではありません。 分析的なアプローチが望ましいかもしれません:

サーバーを使用するすべてのアプリケーションで使用できるすべてのクエリ「テンプレート」を検索します。これらのパターンごとに、カバーリング インデックスを使用している可能性のあるパターンを見つけます。これらは (これもいくつかの穴がありますが...) 次のようなクエリです。

• 基礎となるテーブルへの参照を含める
• インデックス内の列ではない、基礎となるテーブルの列をいかなる形でも引用しないでください。
• インデックスの列よりも選択性の高い、基になるテーブルの検索条件を使用しないでください (その順序どおり)。

または...アプリケーションにアクセスすることさえせずに、 あらゆるユースケースを考える, 、およびこれらのケースに対応するクエリがインデックス内のすべての列から恩恵を受けるわけではない場合。そうすることは、インデックスの最初の数列に関して、インデックスの選択性について比較的よく理解していることを意味します。

Answer 2

あなたは明らかに、監査に使用されるか、または捕捉されないものを、あなたのユースケースとデータポイントの監査を行う場合は、削除候補です。データベースは、このような徹底的な監査を欠いている場合は、トレースを実行しているし、それを保存することで、データベースをヒットするクエリの時間窓の価値を保存することができます。あなたは、トレースを分析し、データベースをヒットしているし、そこインテュイットから列をドロップすることができ、クエリの種類を見ることができます。

トレース解析は、通常、のの指標行方不明の候補を見つけるために使用されるが、私は利用傾向を分析するためにも使用することができることを推測してます。