¿En qué secuencia son consultas y subconsultas ejecutadas por el motor SQL?

Question

Hola me hizo una prueba de SQL y dudosa/curiosidad por una pregunta:

en qué secuencia se consultas y sub-consultas ejecutadas por el motor de SQL?

las respuestas fue

1. consulta primaria -> sub consulta -> sub sub consulta y así sucesivamente
2. sub consulta sub -> sub consulta -> consulta primer
3. toda la consulta se interpreta a la vez
4. no hay una secuencia fija de interpretación, el analizador de consultas toma una decisión sobre mosca

Escogí la última respuesta (solo suponiendo que es más confiable). otros). Ahora la curiosidad:

¿dónde puedo leer sobre esto y brevemente, cuál es el mecanismo de todo eso?

Gracias.

Answer 1

La opción 4 está cerca.

SQL es declarative: le dice al optimizador de consultas lo que quiere y funciona de la mejor manera (sujeto a tiempo/"costo", etc.) de hacerlo.Esto puede variar para las consultas y tablas idénticas externamente según las estadísticas, la distribución de datos, los recuentos de filas, el paralelismo y Dios sabe qué más.

Esto significa que no hay un pedido fijo. Pero no es bastante "sobre la marcha"

Incluso con servidores idénticos, esquemas, consultas y datos que he visto en los planes de ejecución difiere

Answer 2

Por lo general, depende de su DBMS, pero ... Creo que la segunda respuesta es más plausible. La consulta principal generalmente no se puede calcular sin los resultados de la sub consulta.

Answer 3

El motor de SQL intenta optimizar el orden en que se ejecutan (sub) consultas. La parte que decide sobre eso se llama optimizador de consultas. El optimizador de consultas sabe cuántas filas hay en cada tabla, qué tablas tienen índices y en qué campos. Utiliza esa información para decidir qué parte ejecutar primero.

Answer 4

Creo que la respuesta 4 es correcta. Hay algunas consideraciones:

tipo de subconsulta: ¿está correlacionada o no? Considere:

SELECT * 
FROM t1 
WHERE id IN (
      SELECT id 
      FROM t2 
      ) 

Aquí, la subconsulta no está correlacionada con la consulta externa. Si el número de valores en t2.id es pequeño en comparación con t1.id, probablemente sea más eficiente ejecutar primero la subconsulta, y mantener el resultado en la memoria, y luego explorar t1 o un índice en t1.id, haciendo coincidir contra los valores almacenados en caché

Pero si la consulta es:

SELECT * 
FROM t1 
WHERE id IN (
      SELECT id 
      FROM t2 
      WHERE t2.type = t1.type 
      ) 

aquí la subconsulta se correlaciona - no hay manera de calcular la subconsulta menos que se conozca t1.type. Como el valor de t1.type puede variar para cada fila de la consulta externa, esta subconsulta se podría ejecutar una vez para cada fila de la consulta externa.

Por otra parte, el RDBMS puede ser realmente inteligente y darse cuenta de que solo hay unos pocos valores posibles para t2.type. En ese caso, aún puede usar el enfoque utilizado para la subconsulta no correlacionada si puede adivinar que el costo de ejecutar la subconsulta una vez será más barato que hacerlo para cada fila.

Answer 5

Si quieres algo para leer sobre estos temas, obtener una copia de Dentro de SQL Server 2008: consultas T-SQL. Tiene dos capítulos dedicados sobre cómo las consultas se procesan lógica y físicamente en SQL Server.