同じSQLクエリNHibernateアプリケーションの方がSQL Studioより遅いですか？

Question

私たちのアプリケーションは、NHibernateで生成されたSQLクエリを発行します。アプリケーションランタイムでは、SQL Serverデータベースに対してクエリを実行するのに約12秒かかります。 SQLプロファイラには500,000を超える読み込みが表示されます。

しかし、SQLプロファイラを使用して正確なクエリテキストを取得し、SQL Studioから再度実行すると、5秒かかり、4,600未満の読み取りが表示されます。

クエリは、SQLテキストの最後に値が提供されるいくつかのパラメータを使用します。パラメータスニッフィングと非効率なクエリプランについては少し読んでいますが、ストアドプロシージャに関連すると考えていました。たぶんNHibernateは、より長い期間を説明することができるエンティティをインスタンス化しながら、結果セットを開いて保持しますが、NHibernateが実行したのと同じクエリに対して余分な494,000の "読み込み"を説明することができますか？ （追加のクエリは、SQLプロファイラトレースに表示されません。）

クエリは、Hibernate 3.1のLINQ機能を使用してLINQクエリとして指定されています。このような劇的な違いを説明できるのは、哲学の基本的な問題のように思われるため、クエリ自体は含まれていませんでした。

該当する場合、結果にvarbinary（max）列が存在することもありますが、私たちの状況では常にnullが含まれています。

洞察が大変ありがとうございます。

Answer 1

に必ずお読みください：http://www.sommarskog.se/query-plan-mysteries.html

同じ規則がprocsのとsp_executesqlをために適用されます。面倒な計画の大きな理由はvarcharフィールドのnvarcharパラメータで渡すことができます。シークとは対照的にインデックススキャンが発生します。

出力がここでperfに影響するかどうかは疑いがありません。送信されるパラメータの1つ、または基礎となるテーブルの選択性に問題が発生する可能性があります。

プロファイラからの出力をテストする場合は、sp_executesqlを含めて、設定が一致するようにしてください（SET ARITHABORTなど）。そうしないと、新しいプランが生成されます。

も盗聴sys.dm_exec_query_stats