Verifique o tipo de parâmetro (@SSN) que você passa para o SQL. Na maioria das vezes, o parâmetro é adicionado assim:
List<...> GetBySSN(string ssn) {
SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
cmd.Parameters.AddWithValue("@SSN", ssn);
using (SqlDataReader rdr = cmd.ExecuteQuery()) {
...
}
}
Infelizmente, este padrão adiciona o
@SSN parâmetro como um NVARCHAR tipo (ou seja, Unicode). As regras do SQL Server Precedência de tipo de dados
exigem que a comparação entre um NVARCHAR e um VARCHAR seja feita como NVARCHAR, então a consulta é executada como se o seguinte SQL fosse solicitado:select ... from ... where CAST(SSN as NVARCHAR) = @SSN;
Essa consulta não pode se beneficiar de um índice na coluna SSN, portanto, uma verificação de tabela é executada. 90% das vezes que investigo a afirmação 'a consulta é lenta no aplicativo, mas rápida no SSMS' é esse problema, porque a grande maioria dos desenvolvedores realmente executa um diferente consulta no SSMS para comparar (eles usam um argumento VARCHAR ou um valor codificado).
Se esse for realmente o problema, a solução é trivial:especifique explicitamente o tipo de parâmetro como
SqlDbType.VarChar
. 
