Planes de Ejecución para Bases de Datos.

Question

Pregunta 1:

Cuando ejecutamos una consulta, ¿el plan de ejecución cambia cada vez que se ejecuta la consulta?

Si es así, ¿algún impacto en el rendimiento?

Si no, entonces si cambiamos algo en la tabla, es decir, agregando un índice, ¿cómo sabe la base de datos que hay algo que puede usar para cambiar el plan de ejecución para una ejecución más rápida?

PREGUNTA 2:

Pero, ¿cuál es el orden general de ejecución al ejecutar una consulta de combinación, especialmente si hay muchas combinaciones (externas, internas, naturales, si muchas externas).

Answer 1

• Para ser exactos para SQL Server :

Tiene a lo sumo dos planes en caché (uno paralelo, uno no paralelo). Luego, el plan se utiliza con un Contexto de ejecución por usuario. Más información en mi respuesta aquí

• El orden JOIN es irrelevante en casi todos los casos

SQL es declarativo. Esto significa que le dices al motor lo que quieres y el optimizador resuelve el mejor plan (dentro de lo razonable, podría tomar 2 semanas para encontrar el mejor). Es por esto que puede volver a escribir las consultas de muchas maneras diferentes para obtener la misma respuesta.

Como cualquier regla sobre RDBMS, hay excepciones. Para consultas complejas, el optimizador no pasará por cada permutación, por lo que la orden ÚNICA puede ser importante: depende de cuándo el optimizador decida que ya ha tenido suficiente ...

Answer 2

(Suponiendo que el servidor SQL está aquí, no especificó ...)

Los planes de ejecución se almacenan en caché, y en la medida en que parametrice sus consultas, se pueden reutilizar.

Cuando modifica la tabla o los índices subyacentes, SQL Server conoce la fecha de modificación de estas cosas en comparación con el plan de ejecución en caché, y puede volver a evaluar la consulta para las nuevas condiciones. Lo mismo cuando se actualizan las estadísticas ... a veces los datos reales impulsan el plan, no solo el diseño de tabla / índice.

Answer 3

Las uniones no se realizan en un orden basado en interno vs externo, sino en base a lo que el optimizador cree que resultará en que la consulta se ejecute más rápidamente. Los detalles variarán entre las bases de datos. Pero básicamente, el optimizador de consultas intenta optimizar el uso de índices.

Suponga que tiene esta consulta:

select a.foo, b.bar
from a
join b on b.b_id=a.b_id
where a.some_number=42;

Supongamos ahora que tiene un índice único en b.b_id pero no un índice en un número_algo.

El optimizador de consultas tiene dos opciones: podría hacer una lectura secuencial de archivo completo en b, y luego para cada b hacer una lectura secuencial de archivo completo en busca de una coincidencia en b_id y some_number = 42. Eso se lee a ^ b registros. O podría hacer una lectura secuencial de todo el archivo buscando some_number = 42, luego, para cada a, podría usar el índice para encontrar rápidamente el registro de b con b_id correspondiente. Es decir, lea un * 2 registros. Bueno, obviamente, el segundo plan es mucho mejor, así que eso es lo que elegirá.

A medida que agrega más tablas, el cálculo se vuelve más complicado, pero el principio es el mismo. Las combinaciones que resulten en una lectura rápida del índice utilizando valores encontrados en otras tablas se realizarán más adelante, después de que las otras tablas hayan sido leídas. Las tablas que deben leerse secuencialmente sin importar qué, o donde la lectura se basa en constantes en lugar de valores de otros registros, generalmente se leen primero.