¿Cuán determinista es la creación del plan de ejecución en SQL Server?

Dadas las siguientes constantes:

La misma base de datos con la misma estructura (tablas, índices, etc.)
Los mismos datos
El mismo servidor SQL y configuración de hardware
Las mismas estadísticas
Las mismas opciones SET en el cliente
Las mismas versiones de SQL Server
Las mismas banderas de seguimiento

Dadas estas constantes, ¿SQL Server siempre producirá el mismo plan para una consulta dada?

Si no, ¿hay otras consideraciones? ¿Hay también un elemento de no determinismo a considerar también?

sql-server execution-plan determinism

— James L
fuente

será incorrecto decir el mismo plan, pero podemos decir un plan similar. Junto con los factores externos que DBA / Developer puede controlar; Los "algoritmos de optimización del plan de consulta" y los "algoritmos de costo interno de consulta" están escritos dentro del motor del servidor SQL. no tenemos ese control de decir "qué elegir" en todos los sentidos. Podemos configurar env externo para guiar el motor para elegir mejor. para una consulta dada si el optimizador ha presentado dos planes de ejecución con una diferencia de costo de 0.001, entonces supongo que será irrelevante el plan de ejecución que elija.

— Anup Shah

No creo que debas ser demasiado teórico sobre esto. He trabajado 25 años con diferentes bases de datos y casi siempre es posible reescribir una consulta para ejecutarla mejor. Y a veces es muy difícil entender por qué es mejor con una forma de escribir la consulta.

Dadas estas constantes, ¿SQL Server siempre producirá el mismo plan para una consulta dada? Si no, ¿hay otras consideraciones? ¿Hay también un elemento de no determinismo a considerar también?

La compilación de consultas es determinista hasta donde yo sé. Uno de los objetivos de diseño originales de QO era que debería ser posible reproducir los planes de ejecución en un sistema diferente utilizando una copia de la base de datos solo para estadísticas . Hay un par de sutilezas en eso, en torno a los parámetros de configuración, como la cantidad de memoria disponible y la cantidad de procesadores lógicos, pero estos están cubiertos por su lista de cosas para sincronizar.

Advertencia: Eso es cierto siempre que se considere que la palabra 'mismo' en su lista significa exactamente lo mismo en todos los aspectos . Por ejemplo, las "mismas" estadísticas pueden existir en los dos sistemas, pero son exactamente iguales si los pasos del histograma y la información de densidad son idénticos .

Dicho esto, el proceso de optimización también es extremadamente complejo , lo que significa que puede ser difícil garantizar que todas las entradas a este proceso determinista sean idénticas , y que todos los estados internos sean lo suficientemente similares como para garantizar que se tome la misma ruta de código a través del optimizador para un determinado Compilacion. Si la consulta contiene acceso fuera de la base de datos (a otra base de datos o instancia), esos entornos también deben ser idénticos.

Una cosa que agregaría a su lista es verificar que las guías de planes también existan en la segunda base de datos.

El uso de funciones no deterministas como GETDATE()en las consultas podría significar que también obtenga un plan diferente. Si bien el optimizador principal no utiliza el valor directamente, la estimación de cardinalidad sí puede (consulte Evaluación de plegado constante y expresión durante la estimación de cardinalidad ). Sin embargo, no estoy seguro de si esta clase de diferencia cae dentro del alcance de la pregunta, porque ambos sistemas producirían el mismo plan si se ejecutan al mismo tiempo (o, más generalmente, con las mismas variables de entrada, parámetros y valores de función).

— Paul White 9
fuente