SQL Server 2008を使用しています。sprocを実行して実行プランを含めると、インデックスが「欠落」している場合にSQL Serverにアラートが含まれ、インデックスを増やすために追加することをお勧めします。 sprocのパフォーマンス。
少なくとも私にとっては、自動テストでパフォーマンスを重視するsprocを実行してから、実行プランをXMLに含めることは理にかなっていると思います。次に、XMLプランを解析して、SQLServerによって吐き出された警告またはアラートを探します。いずれかが発生した場合、これはテストの失敗と見なされます。前回実行してからクエリコストが大幅に増加した場合は、さらに一歩進んで失敗をスローすることができますが、今のところは単純にしています。
これは誰かがすでにやったことのように聞こえますが、グーグルからは何も見えません。これは、自動化されたパフォーマンステスト/ベンチマークの合理的なアプローチですか？もしそうなら、これを容易にする既存のツールまたはフレームワークはありますか？
ありがとう、
テダーズ
私はこれに反対することをお勧めします。オプティマイザーによって識別される欠落しているインデックスは非常に近視眼的です。つまり、システム全体を考慮せず、このクエリに役立つ可能性があるが、DMLのパフォーマンスを低下させる可能性のあるインデックスを提案します。あなたの心が正しい場所にある間、インデックス分析は科学よりも芸術です（後者は前者に情報を与えることができ、またそうすべきですが）。
これに対するアドバイスは有効です。欠落しているインデックスdmvが、すべて同じことを微調整した半ダースのインデックスを推奨しているのを見てきました。クラスター化されたキーをインクルード列として追加することをお勧めします（クラスター化されたキーは常にインデックス上にあるため、実際には奇妙です）。すでに存在するインデックスを推奨しているのを見てきました。これらのインデックスを適用しないでください。欠落しているインデックスdmvから始めて、より徹底的に調査するのに意味のあるインデックス（影響が大きいなど）を見つける方がよいと思います。次に、これらのインデックスが推奨される原因となったprocについてxmlにクエリを実行します。私はそれをするのに苦労しています。プランキャッシュを毎日フラッシュし、9Kのプロシージャとレガシーアプリからの大量のインラインSQLを使用すると、xmlの解析にかかる時間は非常に長くなります。
または、proc stats dmv（sys.dm_exec_procedure_stats）で開始し、query stats dmv（sys.dm_exec_query_stats）を実行します。平均期間、CPU、およびI/Oの観点から最悪のプロシージャを見つけます。欠落しているインデックスがないかサブセットを確認します（そしてクエリ自体もよく見てください）。それが完了したら、正常に実行されるproc /クエリを確認し始めることができますが、実行頻度が非常に高いため、わずかな改善でも可能です。システムに顕著な影響があります。
私は毎日パフォーマンス統計を収集し、さまざまなカテゴリ（合計CPU、平均CPUなど）の上位20の最悪のプロシージャの要約テーブルをロードします。procがリストを作成するのに十分なパフォーマンスを変更したとき、およびそれが落ちたときのチューニング作業の影響を確認するのが非常に簡単になります。