Le chiamate al database .NET sono lente quando si utilizza l'interoperabilità COM, veloci tramite l'analizzatore di query

Controllare il tipo di parametro (@SSN) che si passa a SQL. Il più delle volte il parametro viene aggiunto in questo modo:

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

Questo modello purtroppo aggiunge il @SSN parametro come NVARCHAR tipo (es. Unicode). Le regole di SQL Server Precedenza del tipo di dati richiedono che il confronto tra un NVARCHAR e un VARCHAR venga eseguito come NVARCHAR, quindi la query viene eseguita come se fosse richiesto il seguente SQL:

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

Questa query non può trarre vantaggio da un indice nella colonna SSN, quindi viene eseguita invece un'analisi della tabella. Il 90% delle volte in cui esamino l'affermazione "la query viene eseguita lentamente dall'app ma velocemente da SSMS" è questo problema, perché la stragrande maggioranza degli sviluppatori esegue effettivamente un diverso query in SSMS per il confronto (usano un argomento VARCHAR o un valore hardcoded).

Se questo è davvero il problema, la soluzione è banale:specificare esplicitamente il tipo di parametro come SqlDbType.VarChar .