Linq a SQL: selección de optimización

En tablas grandes en MSSQL; seleccionar columnas específicas da como resultado una mayor velocidad de la consulta. ¿Se aplica lo mismo a Linq para SQL?

Esto:

var person = from p in [DataContextObject].Persons
             where p.PersonsID == 1
             select new { p.PersonsID, p.PersonsAdress, p.PersonsZipcode };

ser más rápido que esto:

var person = from p in [DataContextObject].Persons
             where p.PersonsID == 1
             select p;

...?

6

6 Respuestas

Recomiendo LinqPad . Es gratis y te permite ejecutar consultas LINQ dinámicamente. Cuando también puede ver el SQL que se genera.

Lo que verá es que la consulta LINQ traducirá la primera consulta en seleccionar solo esas columnas. Entonces es más rápido.

6
agregado

Si está limitando el tamaño del conjunto de resultados al seleccionar solo algunas columnas específicas, entonces SÍ tendrá un efecto.

EDIT ading clarification from comment

Cómo es esto mejor, reducirá el tamaño de los datos resultantes devueltos por SQL Y reducirá el tamaño de los objetos utilizados para almacenar los resultados en la memoria.

Esto se debe al hecho de que, al final, LINQ to SQL genera SQL, por lo que existen los mismos beneficios de rendimiento.

4
agregado
¡Ambos! SQL Server responderá más rápido, lo que limitará los datos transmitidos, y reducirá el tamaño de la colección que contiene los resultados, reduciendo la memoria
agregado el autor Mitchel Sellers, fuente
¿Resultando en una disminución de la asignación de memoria? O una mayor velocidad?
agregado el autor roosteronacid, fuente

Hay 3 aspectos con "más rápido" aquí.

  1. menos datos transmitidos Más rápido. Por otro lado, no obtener eso significativamente más rápido, a menos que selecciones más de una fila o si tu Persona contiene algo otras columnas "pesadas" - largas varchar, imagen, etc.
  2. como señaló J. Curran, menos la memoria asignada significa más rápido. La misma observación que en 1. se aplica aquí.

  3. Su consulta se ejecuta más rápido si tener un índice que contenga todo columnas seleccionadas (o adjuntas a partir de SQL Server 2005). En este caso, el motor de SQL Server no necesita cargar la página con la fila en la memoria, si aún no está allí.

Personalmente, no me molestaría en tratar de optimizar mis consultas de esta manera (a menos que, como dije, sus filas contengan datos binarios o cadenas muy largas que no necesita), en parte porque si luego decide que desea tener más información sobre esta Persona seleccionada, necesitaría cambiar su código de acceso a la BD en lugar de simplemente acceder a una propiedad en su clase POCO/anónima.

3
agregado

Además de lo que han dicho los demás, la nueva estructura sin nombre será mucho más liviana que el objeto Person; sería mucho más rápido, incluso si seleccionó todas las columnas. (La persona tiene métodos/campos, etc. para admitir la escritura del objeto en la base de datos. El tipo sin nombre no lo hace).

1
agregado

Creo que se aplica lo mismo, porque LINQ to SQL traduce las operaciones de consulta Linq a comandos SQL.

1
agregado

Si tiene columnas que son muy grandes, como binarios e imágenes, puede marcar una diferencia significativa, por lo que LINQ to SQL le permite especificar la carga de retraso para ciertas columnas para que pueda seleccionar objetos enteros sin realizar proyecciones 'select new' .

1
agregado