SQL クエリが SSMS では速いのに、ASP.NET では遅いのはなぜですか? このパフォーマンスの差異を修正するにはどうすればよいですか?

クエリ最適化のジレンマ: SSMS と比較して ASP.NET の SQL が遅い

興味深いクエリ最適化の問題で、開発者は次のことに困惑しています。 SSMS で実行されるクエリと、ASP.NET Web サイトで実行される同じクエリとの間には、大幅なパフォーマンスの違いがあります。クエリは、変更後の Web サイトで最初は満足のいくパフォーマンスを示しましたが、翌日には再び低下に戻りました。

さらなるコンテキストを提供するために、問題のクエリには、顧客 ID に基づく動的フィルタリングを含む複雑な結合とサブクエリが含まれています。パラメータ (@customerID)。 Product、Compunix_ProductMMY、Compunix_CustomerMMY、Category、ProductCategory などの複数のテーブルからデータを取得します。

不思議なことに、この同じクエリは他の 2 つの Web サイトでも問題なく動作し、問題がこの特定の Web サイトに限定されていることを示しています。唯一の特徴は、この苦境にある Web サイトが他の Web サイトに比べてかなり多くの製品 (54,000) をホストしていることです。すべての Web サイトとデータベースは同じ物理サーバー上に存在します。

根本原因: パラメータ スニッフィング

調査の結果、問題はパラメータ スニッフィングに起因する可能性が高いことがわかりました。 SQL Server によくあるパフォーマンスの落とし穴。パラメーター スニッフィングには、SQL Server がクエリの最初の実行を分析し、検出されたパラメーター値に基づいて適切な実行プランを決定する最適化操作が含まれます。

ただし、後続の実行中にパラメーター値が変更されると、実行プランが変更される可能性があります。それに応じて適応しないため、最適なパフォーマンスが得られません。このクエリの場合、SSMS での最初の実行では ASP.NET とは異なるパラメーター値が使用され、異なる実行計画とパフォーマンス結果が生じる可能性があります。

緩和戦略

この問題に対処するために、開発者は次のようなパラメータ スニッフィングを軽減する戦略の実装を検討できます。

• オプションの使用 (不明に対する最適化): これにより、パラメータ値に関係なく、SQL Server が実行されるたびにクエリを再コンパイルします。
• 動的を回避するSQL: 文字列の連結を使用して構築された動的 SQL ステートメントは、パラメーターをトリガーできます。鼻をすする。代わりにパラメータ化されたクエリの使用を検討してください。
• ストアド プロシージャの使用: ストアド プロシージャは一度コンパイルされて再利用されるため、パラメータ スニッフィングの必要がなくなります。
• クエリ ヒントの使用: RECOMPILE などのクエリ ヒントを使用してクエリを強制できます。再コンパイル。
• 実行プランについて: SSMS と ASP.NET の両方で実行プランを分析すると、パフォーマンスの違いの根本原因を特定するのに役立ちます。

これらを実装することで、この技術を活用することで、開発者はパラメータ スニッフィングの問題を克服し、SSMS と ASP.NET 全体でクエリの一貫したパフォーマンスを確保できます。

以上がSQL クエリが SSMS では速いのに、ASP.NET では遅いのはなぜですか? このパフォーマンスの差異を修正するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。