¿Es posible darle al optimizador más o todo el tiempo que necesita?


18

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:

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).

Respuestas:


16

Después de trazar la bandera 2301, hay 8780 que realmente hace que el optimizador 'trabaje más' ya que solo le da más tiempo (no ilimitado, como se describe en detalle aquí (ruso) y menos detallado aquí ) para hacer lo suyo.

Descripción detallada en inglés del autor original del artículo ruso. que incluye la propia advertencia del autor:

No se recomienda usarlo nunca en producción .

Combinando los dos y aplicándolos (muy selectivamente a través de la sugerencia de consulta OPTION (QUERYTRACEON 2301, QUERYTRACEON 8780) a una consulta de TVF en línea anidados de 4 niveles (donde solo el que está en la parte inferior haría un trabajo real y los niveles superiores correlacionarían los resultados a través de subconsultas EXISTS) dio como resultado una agradable MERGE JOIN y varios LAZY SPOOL que redujeron el tiempo de ejecución a la mitad.


4

No puedes.

Puede hacer que sus consultas sean "optimizadas para el optimizador" al comprender cómo funciona (bestia compleja, no es necesario saberlo al revés). Sugeriría que si hace algo tan crítico con el tiempo, solucione la consulta en lugar de cambiar el funcionamiento de SQL Server.

Por ejemplo, le gustaría saber cuándo una consulta comienza a escalar de manera menos eficiente que O (n) a medida que cambia el volumen de datos + distribución de datos: dar más tiempo al optimizador no agrega ningún valor aquí.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.