Vérifiez le type de paramètre (@SSN) que vous transmettez à SQL. Le plus souvent, le paramètre est ajouté comme ceci :
List<...> GetBySSN(string ssn) {
SqlCommand cmd = new SqlCommand (@"select ... from ... where [email protected]", conn);
cmd.Parameters.AddWithValue("@SSN", ssn);
using (SqlDataReader rdr = cmd.ExecuteQuery()) {
...
}
}
Ce modèle ajoute malheureusement le @SSN paramètre en tant que NVARCHAR type (c'est-à-dire Unicode). Les règles de SQL Server Priorité des types de données
exigent que la comparaison entre un NVARCHAR et un VARCHAR soit effectuée en tant que NVARCHAR, de sorte que la requête est exécutée comme si le SQL suivant était demandé :
select ... from ... where CAST(SSN as NVARCHAR) = @SSN;
Cette requête ne peut pas bénéficier d'un index sur la colonne SSN donc un parcours de table est effectué à la place. 90 % des fois où j'enquête sur l'affirmation "la requête s'exécute lentement à partir de l'application mais rapidement à partir de SSMS" est ce problème, car la grande majorité des développeurs exécutent en fait un différent requête dans SSMS à comparer (ils utilisent un argument VARCHAR ou une valeur codée en dur).
Si tel est bien le problème, la solution est triviale :spécifiez explicitement le type de paramètre en tant que SqlDbType.VarChar
.
