SSMSのコードは、アプリケーションで実行するコードとは異なります。アプリケーションの次の行は、NVARCHARパラメーターを追加します：
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
SSMSスクリプトで、それをVARCHARとして宣言します：
declare @clientID varchar(200)
データ型の優先順位の規則により、Where client_id = @clientID @clientIDの場合、クエリの式はSARG対応ではありません タイプはNVARCHARです（私は信頼を飛躍させており、client_idと想定しています 列のタイプはVARCHARです）。したがって、アプリケーションは、SSMSクエリがクイックキーシークを実行できるテーブルスキャンを強制します。これは、Parameters.AddWithValueの使用に関するよく知られた理解されている問題であり、以前の多くの記事で説明されています。データアクセスコードがデータベースのパフォーマンスに与える影響を参照してください。問題が理解されると、解決策は簡単です。
-
タイプを受け入れるコンストラクターを使用してパラメーターを追加します：
Parameters.Add("@clientID", SqlDbType.Varchar, 200)（そしてする キャッシュの汚染を防ぐために明示的な長さを渡します。パラメータの長さが正しく指定されていない場合のクエリのパフォーマンスとキャッシュの問題の計画を参照してください -
または SQLテキストでパラメータをキャストします：
where client_id = cast(@clientID as varchar(200))。
最初のソリューションは、SARG能力の問題に加えて、キャッシュ汚染の問題も解決するため、優れています。
また、アプリケーションでは低速、SSMSでは高速を読むことをお勧めしますか？パフォーマンスの謎を理解する