Linq to SQL et Codepages dans SQL généré

Question

Nous avons une requête peu performante dans L2S. La requête réelle ressemble à ceci:

SELECT * 
FROM Table 
WHERE 
    ([ColA] IN (@p0) AND ColB = @p1) 
    OR ColB IN (@p2, @p3, @p4, @p5) 
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [220] 
-- @p1: Input VarChar (Size = 14; Prec = 0; Scale = 0) [CountryDefault] 
-- @p2: Input NVarChar (Size = 0; Prec = 0; Scale = 0) [] 
-- @p3: Input NVarChar (Size = 0; Prec = 0; Scale = 0) [] 
-- @p4: Input NVarChar (Size = 7; Prec = 0; Scale = 0) [WF1 1XU] 
-- @p5: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [WF1] 
-- Context: ProfiledSqlProvider(Sql2008) Model: AttributedMetaModel Build: 3.5.30729.1 

Un problème est une fusion tri en raison de la OR, mais nous cherchons à cela.

L'autre problème est plus intéressant. L'un de nos administrateurs de base de données a signalé que la conversion de la page de codes génère un certain nombre de performances entre les paramètresetet la colonne qu'ils comparent avec VarChar. La chose étrange est de savoir comment L2S a choisi que certains de ces paramètres soient NVarChar, et le paramètre p1 soit VarChar. Dans le code, ce sont toutes des chaînes, bien que p1 soit une chaîne littérale alors que les autres sont des variables. Notez qu'ils sont tous comparés à la même colonne (ColB), donc cela n'a rien à voir avec le type de données de la colonne.

Comment les L2 décident-ils du type de données à utiliser lors de la génération de la requête, en fonction des valeurs transmises? Si possible, comment puis-je contrôler cela?

Answer 1

Une solution de contournement a été fournie dans this thread qui convertit efficacement tous les paramètres en types corrects.