Il tuo codice in SSMS non è lo stesso che esegui nella tua applicazione. Questa riga nell'applicazione aggiunge un parametro NVARCHAR:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
mentre nello script SSMS lo dichiari come VARCHAR:
declare @clientID varchar(200)
A causa delle regole di Data Type Precedence, Where client_id = @clientID l'espressione nella tua query non è compatibile con SARG dove @clientID è di tipo NVARCHAR (sto facendo un atto di fede e presumo che client_id colonna è di tipo VARCHAR). L'applicazione quindi forza una scansione della tabella in cui la query SSMS può eseguire una ricerca rapida della chiave. Questo è un problema ben noto e compreso con l'utilizzo di Parameters.AddWithValue ed è stato discusso in molti articoli in precedenza, ad es. vedere Come il codice di accesso ai dati influisce sulle prestazioni del database. Una volta compreso il problema, le soluzioni sono banali:
-
aggiungi parametri con il costruttore che accetta un tipo:
Parameters.Add("@clientID", SqlDbType.Varchar, 200)(e fai passa la lunghezza esplicita per prevenire l'inquinamento della cache, consulta Interrogare le prestazioni e pianificare i problemi della cache quando la lunghezza del parametro non è specificata correttamente -
o eseguire il cast del parametro nel testo SQL:
where client_id = cast(@clientID as varchar(200)).
La prima soluzione è superiore perché risolve il problema dell'inquinamento della cache oltre al problema della capacità SARG.
Ti consiglierei anche di leggere Lento nell'applicazione, Veloce in SSMS? Comprendere i misteri delle prestazioni
