まず、EF クエリのコンパイルは、ストアド プロシージャを使用することで得られるパフォーマンス上の利点とは何の関係もありません。
http://msdn.microsoft.com/en-us/library/cc853327.aspxによると、クエリが概念モデルに対して実行されると、次の操作が発生します。
- メタデータの読み込み
- データベース接続を開く
- ビューの生成
- クエリの準備
- クエリの実行
- 型の読み込みと検証
- 追跡
- オブジェクトの実体化
そして、に関する説明Preparing the query：
クエリ コマンドを作成し、モデルとマッピング メタデータに基づいてコマンド ツリーを生成し、返されるデータの形状を定義するためのコストが含まれます。Entity SQL クエリ コマンドはキャッシュされるため、後で同じクエリを実行する場合はさらに時間がかかりません。コンパイル済みの LINQ クエリを使用して、後の実行でこのコストを削減することもできます。
そのため、クエリをコンパイルして後で再利用すると、その後のすべてのクエリ実行中にアプリケーションでこの操作にかかる時間を節約できます。ただし、データベースに対して実行される、生成された SQL コードに影響を与えないようにする必要があります。クエリをコンパイルするときに得られるパフォーマンス上の利点は、アプリケーション レベルにあります。
一方、生成された SQL コードに満足できず、データベース レベルでパフォーマンスを最適化したい場合は、通常、ストアド プロシージャを使用します。
コメントに応じて編集し、編集します。
EFクエリをコンパイルすると、データベースに対して実行される生成されたSQLコードが何らかの形で変更されるという印象を受けているようです（コンパイルされたクエリはパラメータ化されたSQLクエリになると述べていますか？）。そうではありません。クエリを直接実行するか使用するかに関係なくcompiledQuery.Invoke、同じ SQL コードが DB に対して実行されます。さらに、それを完全に制御することはできず、可能な限り最良の方法で生成するために ORM に依存します。最適でない場合もあり、これが SP の出番です。
要約すると：
- クエリのコンパイルは、純粋にアプリケーション側の最適化です。コードで再利用されるクエリをコンパイルする時間を節約できます。
- ストアド プロシージャを使用して SQL コードを微調整し、目標にできるだけ近づけることができるため、データベース レベルで最高のパフォーマンスを得ることができます。
1 つの手法が他の手法の代わりになることは決してありません。