Las llamadas a la base de datos .NET son lentas cuando se usa COM Interop, rápidas a través del analizador de consultas

Verifique el tipo de parámetro (@SSN) que pasa a SQL. La mayoría de las veces, el parámetro se agrega así:

List<...> GetBySSN(string ssn) {
   SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
   cmd.Parameters.AddWithValue("@SSN", ssn);
   using (SqlDataReader rdr = cmd.ExecuteQuery()) {
     ...
   }
}

Desafortunadamente, este patrón agrega el @SSN parámetro como NVARCHAR tipo (es decir, Unicode). Las reglas de SQL Server Precedencia de tipos de datos requieren que la comparación entre un NVARCHAR y un VARCHAR se realice como NVARCHAR, por lo que la consulta se ejecuta como si se solicitara el siguiente SQL:

select ... from ... where CAST(SSN as NVARCHAR) = @SSN;

Esta consulta no puede beneficiarse de un índice en la columna SSN, por lo que se realiza una exploración de la tabla en su lugar. El 90% de las veces que investigo la afirmación "la consulta se ejecuta lentamente desde la aplicación pero rápido desde SSMS" es este problema, porque la gran mayoría de los desarrolladores en realidad ejecutan un diferente consulta en SSMS para comparar (usan un argumento VARCHAR o un valor codificado).

Si este es realmente el problema, la solución es trivial:especifique explícitamente el tipo de parámetro como SqlDbType.VarChar .