いくつかのストアドプロシージャの最適化に取り組んでいる間、DBAに座って、高いブロッキングおよび/または高い読み取り/書き込みアクティビティでいくつかのストアドプロシージャを実行しました。
DBAが言及したことの1つTABLEは、再コンパイルを回避するために、ストアドプロシージャの最上部ですべての変数（特に変数）を宣言する必要があることです。
これは私がこれを聞いた最初のものであり、私たちが持っているすべての異なるストアドプロシージャを再検討する前に、いくつかの確認を探していました。彼はそれを「コードの遅い表示」と呼び、再コンパイルはブロッキングを説明するスキーマをロックしていました。
すべての変数宣言をストアドプロシージャの先頭に移動すると、再コンパイルが減りますか？
回答:
番号。
これは、昔（少なくともSQL Server 2000以降ではない）真実だった、または決して真実ではなかったため、DBAは彼の推奨事項を次の推奨事項と混同しただけです。
ストアドプロシージャの開始時に一時テーブルのすべてのDDLステートメント（インデックスの作成など）をグループ化することが重要です。これらのDDLステートメントを一緒に配置することにより、スキーマの変更による不要なコンパイルを回避できます。
このページのこの推奨事項の背後にある理由の別の説明を見つけることができます。
私たちは見てみましょう場合は、このマイクロソフトKB、我々は、ストアドプロシージャの再コンパイルの原因は、以下の（SQL Serverの2005+）のいずれかであることを参照してください。
- スキーマが変更されました。
- 統計が変更されました。
- DNRを再コンパイルします。
- 設定オプションが変更されました。
- 一時テーブルが変更されました。
- リモート行セットが変更されました。
- 閲覧許可の変更。
- クエリ通知環境が変更されました。
- MPIビューが変更されました。
- カーソルオプションが変更されました。
- 再コンパイルオプション付き。
変数を宣言する@table_variableことはDDLとしてカウントされないため、変数を宣言すると（テーブル変数（つまり）であっても）これらのイベントをトリガーできません。変数（テーブル変数も含む）は、T-SQLプログラミング専用に使用される一時オブジェクトです。そのため、テーブル変数は統計情報を取得せず、トランザクションにバインドされません。 変数（テーブルまたは非テーブル）の宣言は、プロシージャの再コンパイルをトリガーできません。
一時テーブル（すなわち作成#temp_table）またはインデックスを、しかし、あるデータベースの物理的な定義に影響を与えDDL。一時テーブルとインデックスは、統計とトランザクション制御を備えた「実際の」オブジェクトであるため、作成すると、上記のリストのイベント1、2、または5のいずれかが発生し、プロシージャの再コンパイルがトリガーされます。
違いを生じさせたり、コンパイルロックを減らしたり、再コンパイルの回数を減らして変数をスタックの途中または最上部で宣言することはできません。読みやすくするために、トップでこれを行うことがよくあります。
質問の「私のDBAの考え方」の部分にたどり着くために、私が思いつくことができる唯一のことは（彼らが以前に何かを考えていたというニックの点を除いて）おそらくパラメータースニッフィングについて話していた（参照シンプルトークのこのリンクのオプション2 ）
ブロッキングについて->真のブロッキングが見られる場合、それはDBAが話している可能性が最も高いコンパイルロックの競合ではありません。これに影響する特定の事柄があることは事実ですが（たとえば、スキーマを修飾するテーブルではなく、ストアドプロシージャコールを修飾するスキーマではありません）、これは確かに高い読み取りの原因ではなく、おそらくブロックの原因ではありません。これらのコンパイルロックを回避するには、できる限りのことを確実に行う必要があります。しかし、変数の場所を気にするよりも重要なタスクとして、ストアドプロシージャコードの残りのチューニングと最適化を検討します。ここで問題が発生していないことを確認する場合は、コンパイルロックを特定して解決する方法を読むこともできます。
これらの前/後の例を投稿すると、ここでDBAが推進していることを確認できます。