У нас плохо работает запрос в L2S. Фактический запрос выглядит примерно так:
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
Одной из проблем является сортировка слиянием в результате OR, но мы изучаем это.
Другая проблема более интересна. Один из наших администраторов баз данных отметил, что при преобразовании кодовой страницы наблюдается значительное снижение производительности между параметрами NVarChar и столбцом, с которым они сравниваются VarChar.
Странная вещь заключается в том, как L2S выбрал для некоторых из этих параметров значение NVarChar, а для параметра p1 - значение VarChar. В коде все они являются строками, хотя p1 является строковым литералом, а остальные являются переменными. Обратите внимание, что все они сравниваются с одним и тем же столбцом (ColB), поэтому это никак не связано с типом данных столбца.
Как L2s решает, какой тип данных использовать при генерации запроса на основе переданных значений? Если возможно, как мне это контролировать?