クエリプランをステートメントで分割して再利用できるようにした方がよいでしょうか。

クエリによってクエリプランがどのようにコンパイル、格納、および取得されるかについての限られた知識から、複数ステートメントクエリまたはストアドプロシージャがクエリプランを生成し、クエリプランキャッシュに格納されて、今後の実行でクエリによって使用されることを理解しています。

このプランは、クエリハッシュを使用してクエリプランキャッシュから取得されると思います。つまり、クエリを編集して実行すると、ハッシュが異なり、クエリプランキャッシュで一致するハッシュが見つからないため、新しいプランが生成されます。

私の質問は次のとおりです。ユーザーがマルチステートメントクエリのステートメントの1つであるステートメントを実行した場合、マルチステートメントクエリのキャッシュに既にあるクエリプランの関連部分を使用できますか？ハッシュ値が明らかに一致しないため、答えはノーだと思いますが、マルチステートメントクエリの各ステートメントをハッシュして、クエリから個々のステートメントを実行しているユーザーが使用できるようにした方がよいでしょうか？

私は考慮していない複雑な問題があると思います（そして、私が本当に知りたいのはこれらです）が、より多くのスペースを使用し、さらに多くのクエリプランに同じ「ステートメントプラン」を格納することができるようです生成するCPUと時間。

私の無知を示​​しているだけかもしれません。

ユーザーがマルチステートメントクエリのステートメントの1つであるステートメントを実行する場合、マルチステートメントクエリのキャッシュに既にあるクエリプランの関連部分を使用できますか？

いいえ。SQLServerでのプランの再利用の基本単位はバッチです。

クエリから個々のステートメントを実行するユーザーが使用できるように、マルチステートメントクエリの各ステートメントをハッシュする方が良いでしょうか？

高レベルのプランの再利用のために調整されたシステムは、SQL Server上の再利用可能なオブジェクト（プロシージャ、関数、トリガーなど）に共通のコードを（適切な粒度で）配置します。また、アプリケーションで生成されたコードまたはクライアント側のコードを明示的にパラメーター化します。プランを最大限に再利用するには、これらの生成されたバッチは、パラメーター値のみが異なる必要があります。

考慮していない複雑な問題があると思います

SQL Serverがステートメントレベルではなく、バッチレベルでキャッシュして再利用するように設計された理由を尋ねているようです。元の設計者以外の誰もがこの質問に正式に答えることができるとは思えません。とにかく、バッチは比較的自己完結型の自然な作業単位であり、実装の複雑さと計画の再利用確率の間の妥当なトレードオフを表すため、バッチは使用するのに自然な粒度であるように思えます。

完全に自己完結型ではないバッチを作成するいくつかのことがあります（たとえば、ストアドプロシージャの境界を越えて作成および参照されるローカル一時テーブル）。これらの例外により直交性が低下し、長年にわたって予期しない「設計上の」動作やバグに関連付けられてきました。