Entity Framework CoreはADO .NETおよびストアドプロシージャを使用するよりも遅いですか？
仕事用の新しいソフトウェアの設計を検討しています。個人的なプロジェクトでEF Coreをかなり使用しています。
私の考えでは、EF Coreは、データを返す基になるデータプロバイダーのクエリを生成します。これらのクエリはアドホック、またはSSMSまたは同等のものを介してMSSQLデータベースでクエリを実行するのと同じです。
ストアドプロシージャを使用すると、ストアドプランを取得できるので、プランを再生成する必要がないため、次回はストアドプロシージャの実行が速くなります。したがって、エンタープライズシステムの場合、EF Coreは、たとえばDapperやストアドプロシージャなどを使用するよりもデータ操作にかなり時間がかかります。
これは完全に間違っていますか？ MSSQLのEF Coreはなんらかの理由で実行プランをキャッシュし、パフォーマンスの違いをそれほど大きくしませんか？または、私はこの全体を前から後ろに持っていますか？
ストアドプロシージャを使用すると、ストアドプランを取得できるので、プランを再生成する必要がないため、次回はストアドプロシージャの実行が速くなります。
それは今日では本当に本当ではありません。 15〜25年前にあなたが言ったことは本当でしたが、RDBMSは最近非常に洗練されたソフトウェアです。以前に実行したクエリを送信するタイミングを検出し、実行プランを再利用できます。考えてみれば、パラメータ化されたクエリでそれがどのように実現できるかを簡単に考えられるはずです。そのため、クエリ内の値でも、それがどのように行われるかについて考えることは、大きな精神的飛躍でさえありません。
そのため、現在、ストアドプロシージャは、通常のSQLクエリよりもパフォーマンスに関してほとんどメリットがありません。これらは、クエリに複雑なアクセス許可が関連付けられている特定の状況や、その他のいくつかのまれな状況で引き続き役立ちます。
SPの古い利点のほとんどは、ストレートSQLで今すぐ取得できます。EFは、必要な場合に手書きクエリをサポートします。
テストしてみてください。 EFCoreを使用してコードを記述します。通常、これはかなりうまく機能します。 Linqクエリの構造と、その結合構文に慣れる方法に注意してください。
遅い場合は、必要なデータのみをリクエストするようにしてください。オブジェクトを非選択するクエリを選択すると、必要な列のみを取得できます。
データベースに保存する必要がない場合は、エンティティトラッキングなしで実行します。
他のすべてが失敗し、確信のあるEFが遅い場合でも、未加工のSQLを記述したり、ストアドプロシージャを呼び出したりできます。これは、ビジネスロジックがスタックのレイヤー全体に広がり、テストが困難になることを意味します。
場合によります！
ストアドプロシージャは、EFまたはその他のメカニズム（SSMSを含む）によってアドホックに生成された場合でも、SQL Serverは通常のクエリの実行プランもキャッシュするため、本質的に高速ではありません。
ただし、データがクライアントとサーバーの間で行き来する必要がないため、複数のクエリまたは一時的な結果が含まれている場合、ストアドプロシージャの方がパフォーマンスが高い場合があります。したがって、複数のステップ、一時テーブル、または条件付きのストアドプロシージャは、同等のEFコードよりもおそらく高速です。
ただし、クライアント側でエンティティのキャッシュを実行するため、EFには他の利点もあります。したがって、どちらのアプローチも間違いなく速いとは言えません。それはアプリケーションに依存します。
これは完全に間違っていますか？
はい。ストアドプロシージャは、「通常の」SQLクエリよりも高速ではありません。
EFコアとSqlClientのパフォーマンスの問題が見つかるのは、EFが非効率的なクエリを生成した場合です。これは、EFオブジェクトを複数の目的で使用する場合や、クエリの一部として実行する複雑なロジックがある場合に発生することがあります。
クエリをハードコーディングすると、変更の制御とパフォーマンスの可視性が向上します。
その上、オブジェクトへの逆シリアル化が行われていることは明らかですが、他のメソッドを使用してこれを大幅に高速化することはほとんどありません。