クエリのパフォーマンスが悪い

処理するデータ量に応じて、通常0.5〜6.0秒で実行される大きな（10,000行以上）手順があります。過去1か月間で、FULLSCANで統計を更新してから30秒以上かかりました。速度が低下すると、sp_recompileは問題を「修正」し、夜間統計ジョブが再度実行されるまで待機します。

低速と高速の実行プランを比較することで、特定のテーブル/インデックスに絞り込みました。実行速度が遅い場合は、特定のインデックスから約300行が返されると推定され、実行速度が速い場合は1行と推定されます。実行速度が遅い場合はインデックスでシークを行った後にテーブルスプールを使用し、実行速度が速い場合はテーブルスプールを実行しません。

DBSS SHOW_STATISTICSを使用して、インデックスヒストグラムをExcelでグラフ化しました。私は通常、グラフがより「ローリングヒル」であると予想しますが、代わりにそれは山のように見え、最高点はグラフ上の他のほとんどの値よりも2倍から3倍高くなります。

FULLSCANなしで統計を更新すると、より正常に見えます。その後、もう一度FULLSCANで実行すると、上記のように見えます。

これは、パラメータスニッフィングの問題のように感じられ、特に上記の（一見）奇妙なインデックス分布に関連しています。

プロシージャはテーブル値パラメーターを受け取りますが、パラメーター値パラメーターでパラメーターのスニッフィングを行うことができますか？

編集：プロシージャは、他に12個のパラメーターも受け取ります。そのうちのいくつかはオプションで、そのうちの2つは開始日と終了日です。

ヒストグラムは奇妙ですか、それとも間違ったツリーを吠えていますか？

クエリを調整したり、インデックスを調整したりすることは確かに快適です。それがすばらしい修正である場合、その時点での私の質問は、歪んだヒストグラムについての詳細です。

これはPK IDENTITYクラスター化インデックスであることを述べておきます。互いに通信する2つのシステムがあり、1つはレガシーシステムで、もう1つは新しい自家製システムです。どちらのシステムも同様のデータを保存します。新しいシステムのこのテーブルのPKを同期させるために、古いシステムにデータが追加されない場合でも（RESEEDが実行された場合でも）、PKが増加します。したがって、この列の番号付けにいくつかのギャップがある可能性があります。レコードが削除されることはほとんどありません。

どんな考えでも大歓迎です。より多くの情報を収集/含めることができて、とてもうれしいです。

これは、最終的にパラメータスニッフィングに関連しています。統計情報が再構築された直後に、このクエリの奇妙に形成されたバージョンが実行されていたのは偶然です。したがって、キャッシュされたプランは、大部分の呼び出しを表すものではありませんでした。日付パラメーターをローカル変数にコピーするトリックを使用しましたが、これは問題なく機能し、パフォーマンスへの影響はほとんどありません。これは、ヒストグラムが「オフ」に見える理由には答えませんが、パフォーマンスの問題を説明します。