Kontrollera vilken typ av parameter (@SSN) du skickar till SQL. Oftast läggs parametern till så här:
List<...> GetBySSN(string ssn) {
SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
cmd.Parameters.AddWithValue("@SSN", ssn);
using (SqlDataReader rdr = cmd.ExecuteQuery()) {
...
}
}
Det här mönstret lägger tyvärr till @SSN
parameter som en NVARCHAR
typ (dvs. Unicode). Reglerna för SQL Server Datatypsprioritet
kräver att jämförelsen mellan en NVARCHAR och en VARCHAR görs som NVARCHAR, så frågan exekveras som om följande SQL begärdes:
select ... from ... where CAST(SSN as NVARCHAR) = @SSN;
Den här frågan kan inte dra nytta av ett index i SSN-kolumnen så en tabellsökning utförs istället. 90 % av gångerna jag undersöker påståendet "frågan går långsamt från appen men snabbt från SSMS" är detta problem, eftersom den stora majoriteten av utvecklare faktiskt kör en annan fråga i SSMS att jämföra med (de använder ett VARCHAR-argument eller ett hårdkodat värde).
Om detta verkligen är problemet är lösningen trivial:ange explicit parametertypen som SqlDbType.VarChar
.