クエリのパフォーマンスが低い
処理するデータの量に応じて、通常0.5〜6.0秒で実行される大きな（10,000行以上）手順があります。過去1か月間で、FULLSCANで統計を更新してから30秒以上かかりました。速度が低下すると、sp_recompileは問題を「修正」し、夜間統計ジョブが再度実行されます。
低速と高速の実行プランを比較して、特定のテーブル/インデックスに絞り込みました。実行速度が遅い場合、特定のインデックスから約300行が返されると推定されます。実行速度が速い場合、1行と推定されます。実行速度が遅い場合はインデックスでシークを行った後にテーブルスプールを使用し、実行速度が速い場合はテーブルスプールを実行しません。
DBSS SHOW_STATISTICSを使用して、Excelでインデックスヒストグラムをグラフ化しました。私は通常、グラフがより「ローリングヒル」であると期待しますが、代わりにそれは山のように見え、最高点はグラフの他のほとんどの値よりも2x-3x高くなります。
FULLSCANなしで統計を更新すると、より正常に見えます。その後、FULLSCANで再度実行すると、上記のように見えます。
これは、パラメータスニッフィングの問題のように感じられ、特に上記の（一見）奇妙なインデックス分布に関連しています。
プロシージャはテーブル値パラメーターを受け取りますが、パラメーター値パラメーターでパラメータースニッフィングを実行できますか？
編集：プロシージャは、他に12のパラメータを受け取ります。そのうちのいくつかはオプションで、そのうちの2つは開始日と終了日です。
ヒストグラムは奇妙ですか、それとも間違ったツリーを吠えていますか？
クエリを調整したり、インデックス作成を調整したりすることは確かに快適です。それがすばらしい修正である場合、その時点で私の質問は歪んだヒストグラムについての詳細です。
これはPK IDENTITYクラスター化インデックスであることを述べておきます。互いに通信する2つのシステムがあり、1つはレガシーシステムで、もう1つは新しい自家製システムです。どちらのシステムも同様のデータを保存します。それらを同期させるために、新しいシステムのこのテーブルのPKは、データが来なかった場合でも（RESEEDが実行された場合でも）古いシステムに追加されたときに増分されます。したがって、この列の番号付けにいくつかのギャップがある可能性があります。レコードが削除されることはほとんどありません。
どんな考えでも大歓迎です。より多くの情報を収集/含めることができて、本当に嬉しいです。
これは、最終的にパラメータスニッフィングに関連しています。統計が再構築された直後に、このクエリのいくつかの奇妙に形成されたバージョンが実行されていたのは、たまたま起こりました。そのため、キャッシュされたプランは、大部分の呼び出しを表していませんでした。日付パラメーターをローカル変数にコピーするトリックを使用しましたが、これは問題なく機能し、パフォーマンスへの影響はほとんどありません。これは、ヒストグラムが「オフ」に見える理由には答えませんが、パフォーマンスの問題を説明します。