回答:
多くの理由。
私が考えることができる最大の1つは、欠落したインデックスDMVが既存のインデックスを考慮しないことです。
例：
のテーブルがありますColA, ColB, ColC。
現在、にインデックスがありますColA。インデックスDMVが見つからない場合は、にインデックスを追加することをお勧めします(ColA, ColB)。これは正しいかもしれませんが、既存のインデックスに2番目のキーとして追加するのが賢明ですColB。そうしないと、カバレッジが重複し、スペースとオーバーヘッドが無駄になります。
同様に、にインデックスがある場合、にインデックスをColB INCLUDE (ColA)提案する場合がありますColB INCLUDE (ColC)。繰り返しますが、スマートなことColCは、既存のインデックスのインクルードリストに追加することです。
推奨されるインデックスのビューは非常に狭く、単一のクエリまたは単一のクエリ内の単一の操作のみを表示します。すでに存在するものや他のクエリパターンは考慮されません。
全体的なインデックス作成戦略を分析し、インデックス構造が効率的で凝集していることを確認するには、思考する人間が必要です。
提案されたすべてのインデックスを追加するだけで問題がなければ、それらを提案する必要さえありません-それらは自動的に実装されます。
duplicate index scriptsやそれに類するものがある場合、これらを追跡するためのリソースがたくさんあります。私は自分のインデックスのほとんどを管理しており、それについては少し知っていますが、それでも時々時々重複を見つけます。
クエリおよびDBスキーマがより複雑になるにつれて、クエリプランによって表示される欠落したインデックス提案の信頼性が一貫して低下することがわかったため、このチューニング手法を慎重に使用することをお勧めします。これは、私の経験におけるさまざまな理由によるものです。
1）「パーセントの改善」は、最も単純なクエリ/最も明白なインデックスを除くすべての方法でオフになる可能性があります。提案されたインデックスを実装した後、クエリのコストが上がるか、使用されず、プランは同じままです。
2）クエリの構築（結合やwhere節が最適化されていないなど）により、クエリプラン自体が最適ではないか、統計が欠落しているか古いために行カウントの推定値がオフになっています。ひどく悪いクエリプランへのインデックス付けは、多くの場合、パフォーマンスが少しずつ向上するだけのバンドエイドソリューションです。
3）全体像が見えない場合があります。これは、グラフィカルプランのみを使用し、XMLを表示せずに複数の欠落したインデックスが提案されているかどうかを確認する場合に特に当てはまります。グラフィカルなプランで最初に表示されるものは、必ずしもクエリに最も影響を与えるものではありません。
4）また、既存のインデックスを変更するときに提案される新しいインデックスの多くの例に遭遇しました。この点に関する他の回答を参照してください、彼らはスポットであり、私はさらに詳しく説明する必要はありません。
なじみのないクエリ/環境で作業して、どこをより深く見るかを調べるとき、出発点として不足しているインデックスの提案のみを使用します。プラン内の演算子（主にシーク/スキャン/結合）を調べ、ツールチップまたはプロパティウィンドウをチェックして、どの列が含まれているかを確認し、それを使用してインデックス候補を決定し、改善をテストします。