欠けているインデックスを盲目的に追加しても大丈夫ですか？
頻繁にSSMSを使用して、遅いストアード・プロシージャーを欠落した索引についてテストします。 「Missing Index（Impact xxx）」が表示されたときはいつでも、新しいインデックスを作成するだけです。これにより、私の知る限り、毎回クエリが高速になります。
これを続けてはいけない理由は何ですか？
多くの理由があります。
私が考えることができる最大の1つは、欠落しているインデックスDMVが既存のインデックスを考慮しないことです。
例：
_ColA, ColB, ColC_のテーブルがあります。
現在、ColAにインデックスがあります。不足しているインデックスDMVは、_(ColA, ColB)_にインデックスを追加することを提案します。これは正しいかもしれませんが、スマートを行うには、既存のインデックスの2番目のキーとしてColBを追加します。そうしないと、カバレッジが重複し、スペースとオーバーヘッドが無駄になります。
同様に、ColB INCLUDE (ColA)にインデックスがある場合、ColB INCLUDE (ColC)にインデックスを提案する場合があります。この場合も、既存のインデックスのインクルードリストにColCを追加するのが賢明です。
提案されたインデックスは非常に狭いビューを持っています-それらは単一のクエリ、または単一のクエリ内の単一の操作のみを見ます。すでに存在するものや他のクエリパターンは考慮されません。
全体的な索引付け戦略を分析し、索引構造が効率的でまとまりがあることを確認するには、思考する人間が依然として必要です。
提案されたすべてのインデックスを追加するだけで問題がなければ、それらを提案する必要さえありません-それらは自動的に実装されます。
クエリとDBスキーマがますます複雑になるにつれて、クエリプランによってポップアップされる欠落したインデックスの提案は一貫して信頼性が低くなることがわかったので、このチューニング手法の慎重な使用をお勧めします。これは、私の経験にはさまざまな理由がありました。
1）「改善率」は、最も単純なクエリ/最も明白なインデックスを除いて、すべての方法でかなりずれている可能性があります。提案されたインデックスを実装した後、クエリのコストが上がるか、または使用されず、プランは同じままであることを確認しました。
2）クエリの構成（結合とwhere句が最適化されていないなど）が原因でクエリプラン自体が最適ではないか、行数の見積もりが欠落/古くなった統計のためにオフになっています。残酷に悪いクエリプランにインデックスを付けることは、多くの場合、パフォーマンスを少しずつ向上させるだけのバンドエイドソリューションです。
3）全体像が見えない場合があります。これは、グラフィカルプランのみを使用し、XMLを表示せずに複数の欠落したインデックスが提案されているかどうかを確認する場合に特に当てはまります。グラフィカルなプランで最初に表示されるものは、必ずしもクエリに最も影響を与えるものではありません。
4）また、既存のインデックスを変更するときに提案される新しいインデックスの多くの例にも遭遇しました。この点については、他の回答をここで参照してください。それらは適切であり、さらに詳しく説明する必要はありません。
見慣れないクエリ/環境を操作してどこをより深く見ればよいかを確認するときの出発点として、不足しているインデックスの提案のみを使用します。計画内の演算子（主にシーク/スキャン/結合）を確認し、ツールチップまたはプロパティウィンドウをチェックして関連する列を確認し、それを使用して、インデックス候補を決定して改善をテストするためのより良い結果を得ました。
主に、インデックスがどのように機能し、保存されるかを知っている多くの理由があります。SSMSが提案するのは、常にインデックスを作成することです。