Tjek hvilken type parameter (@SSN), du sender til SQL. Oftere end ikke tilføjes parameteren sådan her:
List<...> GetBySSN(string ssn) {
SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
cmd.Parameters.AddWithValue("@SSN", ssn);
using (SqlDataReader rdr = cmd.ExecuteQuery()) {
...
}
}
Dette mønster tilføjer desværre @SSN
parameter som en NVARCHAR
type (dvs. Unicode). Reglerne for SQL Server Datatypepræcedens
kræver, at sammenligningen mellem en NVARCHAR og en VARCHAR udføres som NVARCHAR, så forespørgslen udføres, som om følgende SQL blev anmodet:
select ... from ... where CAST(SSN as NVARCHAR) = @SSN;
Denne forespørgsel kan ikke drage fordel af et indeks i SSN-kolonnen, så en tabelscanning udføres i stedet. 90 % af gangene, jeg undersøger påstanden "forespørgslen kører langsomt fra app, men hurtigt fra SSMS", er dette problem, fordi langt de fleste udviklere faktisk kører en anden forespørgsel i SSMS at sammenligne med (de bruger et VARCHAR-argument eller en hårdkodet værdi).
Hvis dette virkelig er problemet, er løsningen triviel:angiv udtrykkeligt parametertypen som SqlDbType.VarChar
.