3

エンティティモデルを介してストアドプロシージャを呼び出すと、直接呼び出すよりもパフォーマンスが大幅に低下するという明らかな理由はありますか？

まず、SPがまったく同じ速度で実行されることは期待していません。また、SPに直接アクセスする場合には呼び出されない、EFが実行する必要のあるさまざまなことがあることを知っています。

それはさておき、3列の文字列を返すクエリがあります。Enterprise Managerを介して実行すると、ほぼ瞬時に実行されます。EF経由で実行すると、約6秒かかります。確かに、結果は複合型にマップされていますが、SQL Server Profilerを介してクエリを実行すると、SQLサーバーで遅延が発生していることがわかります。

SQLServerプロファイラーの2つのソースから実行されているクエリのパフォーマンス

この図では、1はEnterprise Managerから呼び出されているSQLを示し、2はEFを使用してアプリから呼び出されていることを示しています。

私がここで間違っていることは明らかですか？おそらく1、2秒の遅延が予想されますが、違いが大きすぎるようです。

編集：

ADO.Net経由で呼び出された場合、ストアドプロシージャの実行も遅いようです。私の同僚は、.Netがキャッシュしている悪い実行プランと関係があると考えているようです。ストアドプロシージャを編集して再度保存すると、キャッシュにあるものはすべてクリアされたように見え、ストアドプロシージャへのADO.NetとEFの両方の呼び出しが正常に機能します。

他の誰かが以前にこのような何かに遭遇したことがありますか？

4

3 に答える 3

4

SQLServerフォーラムのこのスレッドをご覧ください。それは少し似ており、いくつかの手がかりを与えるかもしれません。つまり、SSMSとADO.NETには異なるSQL Server実行環境オプションがあり、異なる実行プランにつながる可能性があります。SQLServerプランのキャッシュをクリアすると役立つはずです。

于 2012-04-18T16:46:19.660 に答える
2

Pavel Gatilovは、ARITH ABORT設定で頭に浮かんだようですが、私は自分の発見についてもう少し投稿したいと思いました。

SOに関するこの投稿では、回避策について説明した同様の問題について説明しています。EF接続とSQL.Data.Clientの間に、DBへの呼び出しの前に「SETARITHABORTON」を付けるラッパークラスを作成することができます。MSDNのこの記事では、より詳細に説明しています。

変更の複雑さを確認し、アプリケーションをストアドプロシージャの使用からEFの完全な使用に移行することを考慮して、弾丸を噛み、代わりにSP機能をEFデータモデルに移動します。

于 2012-04-20T08:51:03.957 に答える
0

単一のトランザクションでの呼び出しは同じではありません

INSERT INTO foo (col1, col2) SELECT col1, col2 (with all 100 rows of the changes)

100回呼び出すより

EXEC SP_foo_INSERT param1, param2

どちらの場合も生成されたクエリを確認し、そのクエリをデータベースで直接テストしてください。その実行計画を確認してください。

于 2013-08-09T00:58:01.283 に答える