Din kod i SSMS är inte samma kod som du kör i din applikation. Den här raden i din applikation lägger till en NVARCHAR-parameter:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
medan du i SSMS-skriptet deklarerar det som VARCHAR:
declare @clientID varchar(200)
På grund av reglerna för Data Type Precedence är Where client_id = @clientID uttrycket i din fråga är inte SARG-komligt där @clientID är av typen NVARCHAR (jag gör ett språng i tro och antar att client_id kolumnen är av typen VARCHAR). Applikationen tvingar alltså fram en tabellskanning där SSMS-frågan kan göra en snabb nyckelsökning. Detta är ett välkänt och förstått problem med att använda Parameters.AddWithValue och har diskuterats i många artiklar tidigare, t.ex. se Hur dataåtkomstkod påverkar databasprestanda. När problemet väl är förstått är lösningarna triviala:
-
lägg till parametrar med konstruktorn som accepterar en typ:
Parameters.Add("@clientID", SqlDbType.Varchar, 200)(och gör skicka in den explicita längden för att förhindra cacheförorening, se Frågaprestanda och planera cacheproblem när parameterlängden inte har angetts korrekt -
eller casta parametern i SQL-texten:
where client_id = cast(@clientID as varchar(200)).
Den första lösningen är överlägsen eftersom den löser cacheföroreningsproblemet förutom SARG-förmågasproblemet.
Jag skulle också rekommendera dig att läsa Långsamt i applikationen, Snabbt i SSMS? Förstå prestandamysterier