Controleer het type parameter (@SSN) dat u aan SQL doorgeeft. Vaker wel dan niet wordt de parameter als volgt toegevoegd:
List<...> GetBySSN(string ssn) {
SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
cmd.Parameters.AddWithValue("@SSN", ssn);
using (SqlDataReader rdr = cmd.ExecuteQuery()) {
...
}
}
Dit patroon voegt helaas de @SSN
toe parameter als een NVARCHAR
type (bijv. Unicode). De regels van SQL Server Voorrang van gegevenstype
vereisen dat de vergelijking tussen een NVARCHAR en een VARCHAR wordt gedaan als NVARCHAR, zodat de query wordt uitgevoerd alsof de volgende SQL is aangevraagd:
select ... from ... where CAST(SSN as NVARCHAR) = @SSN;
Deze query kan niet profiteren van een index op de SSN-kolom, dus in plaats daarvan wordt een tabelscan uitgevoerd. 90% van de keren dat ik onderzoek doe naar de bewering 'de query wordt traag uitgevoerd vanuit de app, maar snel vanuit SSMS', is dit probleem, omdat de overgrote meerderheid van de ontwikkelaars een andere uitvoert query in SSMS om mee te vergelijken (ze gebruiken een VARCHAR-argument of een hard gecodeerde waarde).
Als dit inderdaad het probleem is, is de oplossing triviaal:specificeer het parametertype expliciet als SqlDbType.VarChar
.