Problema nvarchar de SQL a SQL

Question

He descubierto un gran problema de rendimiento en Linq a SQL.

Al seleccionar de una tabla que utiliza cadenas, los parámetros pasados ​​al servidor sql son siempre nvarchar, incluso cuando la tabla sql es varchar. Esto da como resultado exploraciones de tabla en lugar de búsquedas, un problema de rendimiento masivo.

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

var qa = q.ToArray(); 

el parámetro se pasa a través de como nvarchar, lo que resulta en todo el índice que se convierte de varchar a nvarchar antes de ser utilizados.

Si el parámetro es un varchar es una búsqueda muy rápida.

¿Hay alguna manera de anular o cambiar esto?

Gracias Saludos Craig.

Answer 1

Hmmm. Este era un error conocido con versiones previas a RTM de LINQ-to-SQL, pero por lo que leí en línea, este fue un problema fijo para las comparaciones de igualdad en RTM (aunque todavía está roto para las comparaciones de Contiene()).

De todos modos, aquí hay un hilo en los foros de MSDN con algunas soluciones detalladas: http://social.msdn.microsoft.com/Forums/en-US/linqtosql/thread/4276ecd2-31ff-4cd0-82ea-7a22ce25308b

La solución que más me gusta es ésta:

//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()); 

Por cierto, otro caso vi que esto ocurra se encontraba en una tabla con una distribución impar de valores (por ejemplo, el 50% de la tabla tenía el mismo valor), lo que significa que, dado que el SQL Server desconoce el parámetro en el momento de la compilación, el mejor plan disponible era un escaneo de tabla. Si su distribución también es inusual, las soluciones anteriores no funcionarán, ya que el escaneo no vendrá de la conversión faltante sino de la parametrización misma. En ese caso, la única solución que conocería sería usar una sugerencia de OPTIMIZE FOR y especificar manualmente el SQL.