Wywołania bazy danych .NET są powolne podczas korzystania z COM Interop, szybkie dzięki analizatorowi zapytań

Sprawdź typ parametru (@SSN), który przekazujesz do SQL. Najczęściej parametr jest dodawany w ten sposób:

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

Ten wzorzec niestety dodaje @SSN parametr jako NVARCHAR typ (np. Unicode). Reguły SQL Server Pierwszeństwo typów danych wymagają, aby porównanie między NVARCHAR i VARCHAR było wykonane jako NVARCHAR, więc zapytanie jest wykonywane tak, jakby zażądano następującego kodu SQL:

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

To zapytanie nie może korzystać z indeksu w kolumnie SSN, więc zamiast tego wykonywane jest skanowanie tabeli. 90% przypadków, w których sprawdzam twierdzenie „zapytanie działa wolno z aplikacji, ale szybko z SSMS” to ten problem, ponieważ zdecydowana większość programistów faktycznie uruchamia inne zapytanie w SSMS do porównania (używają argumentu VARCHAR lub wartości zakodowanej na stałe).

Jeśli rzeczywiście jest to problem, rozwiązanie jest trywialne:jawnie określ typ parametru jako SqlDbType.VarChar .