Twój kod w SSMS nie jest tym samym kodem, który uruchamiasz w swojej aplikacji. Ten wiersz w Twojej aplikacji dodaje parametr NVARCHAR:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
podczas gdy w skrypcie SSMS deklarujesz go jako VARCHAR:
declare @clientID varchar(200)
Ze względu na zasady pierwszeństwa typu danych Where client_id = @clientID wyrażenie w zapytaniu nie jest w stanie SARG, gdzie @clientID jest typu NVARCHAR (robię skok wiary i zakładam, że client_id kolumna jest typu VARCHAR). W ten sposób aplikacja wymusza skanowanie tabeli, w której zapytanie SSMS może wykonać szybkie wyszukiwanie klucza. Jest to dobrze znany i zrozumiały problem dotyczący używania Parameters.AddWithValue i był już omawiany w wielu artykułach, m.in. zobacz, jak kod dostępu do danych wpływa na wydajność bazy danych. Gdy problem zostanie zrozumiany, rozwiązania są banalne:
-
dodaj parametry za pomocą konstruktora, który akceptuje typ:
Parameters.Add("@clientID", SqlDbType.Varchar, 200)(i tak) podaj określoną długość, aby zapobiec zanieczyszczeniu pamięci podręcznej, zobacz Wydajność zapytań i zaplanuj problemy z pamięcią podręczną, gdy długość parametru nie została określona poprawnie -
lub rzutuj parametr w tekście SQL:
where client_id = cast(@clientID as varchar(200)).
Pierwsze rozwiązanie jest lepsze, ponieważ oprócz problemu zdolności SARG rozwiązuje problem zanieczyszczenia pamięci podręcznej.
Polecam również lekturę Wolno w aplikacji, Szybko w SSMS? Zrozumienie tajemnic wydajności
