Función escalar de SQL Server versus análisis de plan de ejecución de subconsulta

¿Alguien me puede ayudar a comprender el plan de ejecución de SQL Server para las siguientes consultas?Función escalar de SQL Server versus análisis de plan de ejecución de subconsulta

Esperaba que la versión de la subconsulta (Query 2) se ejecutara más rápido, porque está basada en conjuntos. Este parece ser el caso cuando runnning las consultas de forma independiente - marginalmente - sin embargo, el plan de ejecución muestra los costos de la consulta como 15% vs. 85%, respectivamente:

//-- Query 1 (15%) - Scalar Function 
SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    dbo.GetGalleryImageVotesByGalleryImageId(gi.GalleryImageId) AS Votes 
FROM 
    GalleryImage gi 

//-- Query 2 (85%) - Subquery 
SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    (SELECT COUNT(*) FROM GalleryImageVote WHERE GalleryImageId = gi.GalleryImageId) 
FROM 
    GalleryImage gi

¿Qué me falta aquí; ¿el plan de ejecución omite el costo de la función? Además, ¿hay alguna sugerencia sobre si alguno de los anteriores sería mejor servido con una consulta CTE o OVER/PARTITION?

¡Gracias de antemano!

Fuente

2011-01-20 Robarondaz

¿Las tiene ambas en la misma ventana del editor de consultas? Porque el analizador de consultas los comparará y asignará a cada uno un valor relativo a lo que está en la ventana (15%/85%). – JNK

Sí, de ahí vienen los% values :) – Robarondaz

El tiempo de ejecución de la consulta no siempre es igual al costo. Parece que SQL Server pondera el uso de CPU y RAM más que las lecturas de HDD. – jahu

Nunca confíes en el plan de ejecución. Es una herramienta muy útil para que pueda ver lo que será el plan, pero si quieres métricas reales, siempre su vez en las estadísticas

set statistics io on 
set statistics time on

..y comparar las ejecuciones reales. Las estadísticas pueden decir que la expectativa es del 15%/85%, pero los datos reales le mostrarán a qué se traduce realmente.

No hay ninguna bala de plata para ajustar el rendimiento. Incluso las "mejores" consultas pueden cambiar con el tiempo a medida que cambia la forma o distribución de sus datos.

El CTE no será muy diferente, y no estoy seguro de cómo planea hacer una consulta PARTITION sobre esto, pero puede probar el formulario left join.

SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    count(v.GalleryImageId) AS Votes 
FROM 
    GalleryImage gi 
    LEFT JOIN GalleryImageVote v ON v.GalleryImageId = gi.GalleryImageId 
GROUP BY 
    gi.GalleryImageId, gi.FbUserId

Fuente

2011-01-20 20:04:22 RichardTheKiwi

Saludos, no sabía sobre estadísticas. El tiempo de ejecución real fue de 265 ms (consulta 1) frente a 2 ms (consulta 2); ¡mucho más en línea con lo que originalmente esperaba! – Robarondaz

El optimizador no conoce el costo de la función.

Usted puede ver la CPU y lee y duración a través de perfiles, aunque

Algunas respuestas relacionadas a cuestiones similares. One Two

funciones de tabla Inline se expanden en la consulta principal (que son las macros como visitas)
escalar (su ser) y de múltiples funciones de tabla comunicado no lo hacen y son cajas negras a la consulta "externa"

Fuente

2011-01-20 17:49:17 gbn

¡Gracias por su ayuda! – Robarondaz

Función escalar de SQL Server versus análisis de plan de ejecución de subconsulta

Respuesta

Cuestiones relacionadas