ストアドプロシージャを確実に再コンパイルするには、いくつかの方法があります。
-
WITH RECOMPILEを使用する 、 - ストアドプロシージャを動的にする（
exec()を考えてください ） -
sp_recompileを使用してプロシージャに再コンパイルのマークを付ける 。 - キャッシュされたクエリプランが依存するスキーマの変更
-
DBCC FREEPROCCACHEを呼び出す - クエリレベルでは、プロシージャ内の個々のステートメントをRECOMPILEクエリヒント（SQL 2008）を使用して再コンパイルできます。
再コンパイルの要因
上記のハードファクターに加えて、ストアドプロシージャの再コンパイルの原因は何ですか？まあ、たくさんのこと。これらのいくつかは上記のリストと織り交ぜられていますが、それが明白ではないかもしれないので、それらを再提示したいと思います。
- 大量のデータの挿入または削除（インデックスとテーブルのデータ密度がクエリプランを制御することがよくあります）
- インデックスの再構築（基になるオブジェクトへの変更）
- 一時テーブルの作成/削除（ここでも、基になるDMLの変更）。
- クエリプランは期限切れになります（最近は使用されておらず、SQLはメモリ使用量をクリーンアップしたいと考えています）
これは決して網羅的なリストではありません。クエリオプティマイザは、SQL Serverをどれだけ長く使用していても、進化し、驚きます。ただし、役立つ可能性のあるリソースは次のとおりです。
- ストアドプロシージャの再コンパイルのトラブルシューティング （オールディーズですが、グッディーズ）
- ストアドプロシージャの再コンパイル
- SQLServerストアドプロシージャを最適化して再コンパイルを回避する>
- 実行プランのキャッシュと再利用 （必読）
しかし、待ってください-もっとあります！
そうは言っても、あなたの質問の推測は、再コンパイルは常にパフォーマンスに悪いということです。実際、多くの場合、再コンパイルは適切です。
では、いつ再コンパイルしたいですか？姓で検索するprocの1つの例を見てみましょう。ストアドプロシージャは、'パラメータスニッフィング
を実行します 'これは祝福（それがあなたのために働く場合）と呪い（それがあなたに対して働く場合）です。最初に誰かがZebr%で検索したパス zerbrowskiのために。姓のインデックスは、これが非常に具体的であり、たとえば100万から3行を返すことを認識しているため、1つの実行プランが作成されます。低い行の結果のためにコンパイルされたprocを使用して、次の検索はS%です。 。さて、Sはあなたの最も一般的な名前であり、100万のうち93,543行に一致します。