ストアド プロシージャが SqlCommand よりも SSMS で実行されるのが速いのはなぜですか?

ストアド プロシージャのパフォーマンスの違い: SqlCommand と SSMS

ストアド プロシージャの実行時間は、SQL Server Management Studio 間で大きく異なる場合があります ( SSMS) および System.Data.SqlClient.SqlCommand (パラメーターがない場合でも)鼻をすする。根本原因は、各実行環境で有効になっている SET オプションの違いにある可能性があります。

SQL Server Profiler を使用すると、.NET SQL クライアント データ プロバイダーが省略するいくつかの SET コマンドが SSMS で実行されることが判明しました。これらの SET オプションは、クエリ プランとパフォーマンスに影響を与える可能性があります。この場合の原因として浮上した重要な SET オプションの 1 つは次のとおりです。

SET ARITHABORT ON

この SET オプションが有効になっていると、オーバーフロー、ゼロによる除算、またはその他の例外的な条件が発生する可能性がある算術演算を含むクエリが実行されます。時期尚早に停止します。この動作は、例外の発生を許可する SET ARITHABORT OFF のデフォルト設定とは異なります。

その結果、ストアド プロシージャの実行計画とパフォーマンスは、SET ARITHABORT オプションの影響を受ける可能性があります。ストアド プロシージャ内の算術演算がこの設定の影響を受ける場合、SSMS と SqlCommand の間で実行時間に差が生じる可能性があります。

この問題を軽減するには、アプリケーションで使用されている SET オプションを慎重に確認することをお勧めします。 SQL Server に接続します。 SSMS で使用されるものと同じ SET オプションを SqlCommand で使用することで、パフォーマンスの不一致を回避できます。さらに、SQL Server プロファイラーを利用してアクティブな SET オプションを特定することは、有益なデバッグ手法です。

接続文字列パラメーター、トランザクション動作、MARS (複数のアクティブな結果セット) 設定などの他の要素もパフォーマンスに影響を与える可能性があります。潜在的な寄与要因として考慮する必要があります。

以上がストアド プロシージャが SqlCommand よりも SSMS で実行されるのが速いのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。