Problem z Linq na SQL nvarchar

Question

Odkryłem ogromny problem z wydajnością w Linq do SQL.

Podczas wybierania z tabeli za pomocą ciągów parametry przekazywane do serwera sql są zawsze nvarchar, nawet jeśli tabela sql jest varcharem. Powoduje to skanowanie tabeli zamiast poszukiwań, ogromny problem z wydajnością.

var q = (
    from a in tbl 
    where a.index == "TEST" 
    select a) 

var qa = q.ToArray(); 

Parametr przepuszcza się jako nvarchar, co powoduje, że cały wskaźnik jest przekształcany z VARCHAR nvarchar przed użyciem.

Jeśli parametr jest varchar, jest to bardzo szybkie wyszukiwanie.

Czy istnieje sposób, aby to zmienić lub zmienić?

Dzięki Pozdrawiam Craig.

Answer 1

Hmmm. Był to znany błąd związany z kompilacją LINQ-SQL w wersjach wcześniejszych niż RTM, ale z tego, co czytałem w Internecie, wynikało to ze stałego problemu z porównywaniem równości w RTM (chociaż nadal nie działa w przypadku porównań Contains()).

Niezależnie, tutaj jest wątek na forach MSDN ze niektóre obejścia Szczegółowe: http://social.msdn.microsoft.com/Forums/en-US/linqtosql/thread/4276ecd2-31ff-4cd0-82ea-7a22ce25308b

Obejście lubię najbardziej jest to jedno:

//define a query 
IQueryable<Employee> emps = from emp in dc2.Employees where emp.NationalIDNumber == "abc" select emp; 

//get hold of the SQL command translation of the query... 
System.Data.Common.DbCommand command = dc2.GetCommand(emps); 

//change param type from "string" (nvarchar) to "ansistring" (varchar) 
command.Parameters[0].DbType = DbType.AnsiString; 
command.Connection = dc2.Connection; 

//run 
IEnumerable<Employee> emps2 = dc2.Translate<Employee>(command.ExecuteReader()); 

BTW, kolejny przypadek Widziałem to dzieje się w sposób tabela z nieparzystym rozkładem wartości (np. 50% tabeli miało tę samą wartość), co oznacza, że ​​biorąc pod uwagę, że parametr nie jest znany SQL Server w czasie kompilacji planu, najlepszym dostępnym planem było skanowanie tabeli. Jeśli twoja dystrybucja jest również niezwykła, powyższe rozwiązania nie będą działać, ponieważ skanowanie nie będzie pochodzić z brakującej konwersji, ale raczej z samej parametryzacji. W takim przypadku jedynym obejściem byłoby użycie OPTIMIZE FOR Hint i ręczne określenie SQL.