Seu código no SSMS não é o mesmo código que você executa em seu aplicativo. Esta linha em seu aplicativo adiciona um parâmetro NVARCHAR:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
enquanto no script SSMS você o declara como VARCHAR:
declare @clientID varchar(200)
Devido às regras de Precedência de Tipo de Dados, o
Where client_id = @clientID expressão em sua consulta não é compatível com SARG onde @clientID é do tipo NVARCHAR (estou dando um salto de fé e suponho que client_id coluna é do tipo VARCHAR). Assim, o aplicativo força uma verificação de tabela onde a consulta do SSMS pode fazer uma busca rápida de chave. Este é um problema bem conhecido e entendido com o uso de Parameters.AddWithValue e foi discutido em muitos artigos antes, por exemplo. consulte Como o código de acesso a dados afeta o desempenho do banco de dados. Uma vez que o problema é entendido, as soluções são triviais:-
adicione parâmetros com o construtor que aceita um tipo:Parameters.Add("@clientID", SqlDbType.Varchar, 200)(e faça passe o comprimento explícito para evitar a poluição do cache, consulte o desempenho da consulta e planeje problemas de cache quando o comprimento do parâmetro não for especificado corretamente
-
ou converta o parâmetro no texto SQL:where client_id = cast(@clientID as varchar(200)).
A primeira solução é superior porque resolve o problema de poluição do cache além do problema de capacidade SARG.
Eu também recomendo que você leia Slow in the Application, Fast in SSMS? Entendendo os mistérios do desempenho
