2011-10-19 22 views
5

Tengo un par de meses de experiencia trabajando con Entity Framework y principalmente escribiendo un montón de consultas sobre linq de recuperación de datos. Vengo de un entorno de SQL pesado, y estoy tratando de optimizar algunos de los sql para el rendimiento y la legibilidad si estoy tratando de solucionar problemas de rendimiento.Entity Framework Query Optimization

estoy notando algunos de los SQL generado hace cosas como esta para un tablaA con columnas {col1, col2, col3}

select 
    Extent1.col1 
from 
(
    select col1, col2, col3 from tableA 
) AS Extent1 

Mi pregunta es, ¿cómo puedo evitar que de hacer estas tablas derivadas inútiles , y en su lugar solo haga

select col1 from tableA 

donde es necesario? Parece que no puedo entender por qué a veces esto y otras veces ...

+0

Me interesa escuchar los pensamientos de otras personas; pero creo que este es solo uno de los inconvenientes de usar EF (¿y otros ORM?). Pierde mucho control sobre el SQL real que se genera, y el SQL generado a menudo es bastante malo. – CodingGorilla

+0

posible duplicado de [Mejorar la consulta generada desde el marco de entidad] (http://stackoverflow.com/questions/7418675/improve-query-generated-from-entity-framework) –

Respuesta

4

¿Ha comparado los planes de ejecución de consulta reales de la consulta generada con la forma en que la optimizaría? Puede que te sorprendan los resultados, sé que lo era. Y gané un profundo respeto por los desarrolladores en el equipo de SQL Server que parecen estar haciendo un trabajo excelente al hacer que lo que parece ser una consulta subóptima funcione de la misma manera.

Me interesaría saber si tu experiencia difiere de la mía; Dejé de buscar formas de cambiar las consultas generadas porque, por cada consulta que intenté examinar, no había una diferencia real en el rendimiento.

EDIT: Mi última afirmación no es del todo cierto, definitivamente hay N + 1 situaciones que hay que tener en cuenta, y cualesquiera operaciones por lotes (actualizaciones, eliminaciones e inserciones de varios registros al mismo tiempo) no van a estar ni siquiera cerca en cuanto a su rendimiento a la hora de escribir una consulta a mano debido a la naturaleza del trabajo con registros individuales. Pero las extensiones extrañas esencialmente se eliminan por el optimizador de consultas SQL Server.

+0

Hola Joel, en general tienes razón, pero tengo un par de preguntas desagradables que son de aproximadamente 300 líneas de largo que hacen este negocio de "tablas derivadas inútiles" varias veces a lo largo. Tomar esa consulta y simplemente reemplazar las tablas derivadas con su posterior selección directa de la contraparte de la tabla requiere una gran consulta como esa desde 7 segundos hacia abajo hasta 1 segundo ... así que estoy de acuerdo contigo en su mayor parte, pero tratando de entender cómo puedo optimizar mejor mi linq para que no me encuentre con este problema. – Zom

+0

@Isamu: Generalmente, si puede simplificar su consulta LINQ, SQL también se simplifica. Hay muchas técnicas para hacer esto, pero sin ningún código que observar, es difícil dar consejos específicos. ¿La ganancia de rendimiento> 7x que está informando es un resultado directo de eliminar las columnas innecesarias del código generado por EF, o está haciendo transformaciones más complejas? – StriplingWarrior

+1

Supongo que representó el almacenamiento en caché de consultas cuando probó la diferencia de rendimiento ... Hay una publicación de blog en el blog del equipo EF (http://blogs.msdn.com/b/adonet/archive/2011/07/ 25/generated-sql-improvements-for-tpt-queries.aspx) que está abierto para comentarios sobre cuestiones específicas relacionadas con las mejoras de rendimiento para SQL generado. Esa publicación específica habla de las mejoras que han realizado al tratar con una jerarquía de herencia de clase de tabla por tipo en la versión más reciente. –