Dado que el optimizador no puede tomar todo el tiempo que necesita (tiene que minimizar el tiempo de ejecución y no contribuir a él) para explorar todos los posibles planes de ejecución, a veces se corta.
Me preguntaba si esto se puede anular para que pueda darle al optimizador todo el tiempo que lo necesite (o una cierta cantidad de milisegundos).
No tengo necesidad de esto (cajero automático), pero puedo imaginar un escenario en el que una consulta compleja se ejecuta en un ciclo cerrado y desea obtener el plan óptimo y almacenarlo en caché de antemano.
Por supuesto, si tiene un ciclo cerrado, debe volver a escribir la consulta para que desaparezca, pero tenga paciencia conmigo.
Esto es más una cuestión por curiosidad y también para ver si a veces hay una diferencia entre una optimización en cortocircuito y una completa.
Resulta que puede darle más tiempo al optimizador con el indicador de rastreo 2301. No es exactamente lo que estaba preguntando, pero se acerca.
La mejor información que encontré sobre esto está en Extensiones de modelado del procesador de consultas en SQL Server 2005 SP1 de Ian Jose.
¡Use esta bandera de seguimiento con cuidado! Pero puede ser útil al idear mejores planes. Ver también:
- Artículos etiquetados "nivel de optimización" por Grant Fritchey.
- Antes de actualizar a SQL Server 2008 ... por Brent Ozar.
- Opciones de ajuste para SQL Server cuando se ejecuta en cargas de trabajo de alto rendimiento por parte del soporte de Microsoft.
Estaba pensando en consultas con muchas uniones donde el espacio de solución para el orden de unión explota exponencialmente. La heurística que utiliza SQL Server es bastante buena, pero me preguntaba si el optimizador propondría un orden diferente si tuviera más tiempo (en el rango de segundos o incluso minutos).
fuente