SQL Server sp_ExecuteSQL y planes de ejecución

Tengo una consulta que es superrápida en SQL Server Management Studio y super lenta cuando se ejecuta en sp_ExecuteSQL.SQL Server sp_ExecuteSQL y planes de ejecución

¿Esto tiene que ver con el almacenamiento en caché de los planes de ejecución que no ocurren cuando se ejecuta bajo spExecuteSQL?

Fuente

2010-09-14 AJM

Me pregunto cuando el mito "sp_executesql no guarda en caché" morirá alguna vez - lea [La maldición y las bendiciones de SQL dinámico] (http://www.sommarskog.se/dynamic_sql.html) –

@OMG Ponies - ¿Podría el parámetro sniffing ser un problema con sp_ExecuteSQL? – JNK

@JNK: Desde que experimenté el comportamiento, de todos modos, puse el olfateo anti-param por defecto. –

Nº

Puede ver tanto los planes de ejecución y compararlas utilizando la siguiente consulta.

SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options 
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 
cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa 
where text like '%Some unique string in your query%' 
              and attribute='set_options'

La versión sp_executesql tendrá un objtype de "preparado"

Fuente

2010-09-14 16:26:58

¿Por qué los planes de ejecución serían tan radicalmente diferentes? Por ejemplo, he consultado mi plan de ejecución de consultas directamente desde Sql Management Studio (lleva 3 segundos) y el plan de ejecución desde sp_executeSql (lleva más de 5 minutos). el plan de sp_executeSql ignora por completo algunos de los índices clave que encontró la llamada directa. ¿Alguien puede explicar por qué una llamada de un estudio de administración encuentra claves, pero la llamada a través de sp_ExecuteSql no? –

@NathanTregillus: Probablemente el rastreo de parámetros, puede ver el XML del plan en caché para ver los valores de los parámetros con los que el plan fue realmente compilado. –

gracias por la respuesta @MartinSmith. En realidad, se debió a cómo usamos el contextInfo como filtro en nuestra vista, y cómo no se incluye en el plan de ejecución –

experimentado el mismo comportamiento. (establecer opciones iguales) Consulta regular produciendo un plan paralelo y usando sp_executesql produjo un plan en serie.

declare @xyzParam1 datetime,@xyzParam2 datetime 
select @xyzParam1='Sep 1 2014 12:00:00:000AM',@xyzParam2='Sep 26 2014 11:59:59:000PM' 
SELECT * FROM Theview WHERE departuretime BETWEEN @xyzParam1 AND @xyzParam2 
;

exec sp_executesql N'SELECT * FROM Theview WHERE departuretime BETWEEN @xyzParam1 AND @xyzParam2',N'@xyzParam1 datetime,@xyzParam2 datetime',@xyzParam1='Sep 1 2014 12:00:00:000AM',@xyzParam2='Sep 26 2014 11:59:59:000PM'

I logrado obtener un resultado óptimo modificando la vista utilizada debido a que contenía, por ejemplo, left se une a los datos que siempre se esperaba. (convertido a INNER join)

Ahora la consulta regular elige el mismo plan que el obtenido con sp_executesql y el rendimiento es mucho mejor.

Fuente

2014-09-29 07:50:44 ALZDBA

SQL Server sp_ExecuteSQL y planes de ejecución

Respuesta

Cuestiones relacionadas