SQL クエリが SSMS よりも C# で 3 分遅いのはなぜですか?

コードと SSMS 間のクエリ パフォーマンスの不一致

開発者は、C# コードと SQL Server 管理で同じクエリを実行するときに、パフォーマンスに大きな違いが発生しました。スタジオ (SSMS)。 SSMS ではクエリは 3 秒未満で完了しましたが、アプリケーションで実行すると 3 分以上かかりました。

パフォーマンスの問題の根本原因

さらに調査すると、この問題は、C# コードと SSMS で使用されるクエリ パラメーター間の微妙な違いであることが判明しました。 C# コードでは、クライアント ID のパラメーターは NVARCHAR 型として渡されましたが、SSMS クエリでは VARCHAR 型として宣言されました。

データ型の優先順位の影響

データ型の優先順位規則により、C# クエリの NVARCHAR パラメーターにより、クエリでインデックス シークを利用できませんでした。その結果、テーブル スキャンが発生し、実行時間が大幅に増加しました。対照的に、SSMS クエリの VARCHAR パラメーターを使用すると、クエリ オプティマイザーがインデックス シークを使用できるようになり、実行が高速化されました。

パフォーマンスの問題の解決策

パフォーマンスの矛盾があるため、開発者は 2 つの問題を抱えていました。 options:

• オプション 1: 指定された型のパラメーターを使用する

  型を受け入れるコンストラクターを使用することで、開発者はパラメーターを次のように明示的に定義しました。 VARCHAR 型:

  Parameters.Add("@clientID", SqlDbType.Varchar, 200)

  これにより、パラメーターが正しい型として渡され、クエリの SARG 機能には影響しません。

• オプション 2: SQL クエリでパラメータをキャストする

  あるいは、開発者はキャストすることもできます。 SQL クエリ内のパラメータは次のようになります:

  where client_id = cast(@clientID as varchar(200))

  このメソッドは型の問題も解決し、クエリでインデックス シークを利用できるようにします。

追加の推奨事項

• 明示的なパラメータの長さを使用する:キャッシュ汚染を防ぐため、開発者はオプションを使用するときに VARCHAR パラメータの長さを明示的に指定することをお勧めします。 1.
• 参考推奨記事: 開発者は、「アプリケーションでは遅く、SSMS では高速?」という記事を参照することをお勧めします。コードと SSMS の間のパフォーマンスの不一致についてさらに詳しくは、「パフォーマンスの謎を理解する」を参照してください。

以上がSQL クエリが SSMS よりも C# で 3 分遅いのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。