WHERE y JOIN orden de operación

Question

Mi pregunta es similar a esta SQL order of operations pero con un pequeño giro, por lo que creo que es justo preguntar.

Estoy usando Teradata. Y tengo 2 tablas: table1, table2.

table1 tiene solo una columna id.
table2 tiene las siguientes columnas: id, val

Puedo estar equivocado, pero creo que estas dos afirmaciones dan los mismos resultados.

Declaración 1.

SELECT table1.id, table2.val 
FROM table1 
INNER JOIN table2 
ON table1.id = table2.id 
WHERE table2.val<100 

Declaración 2.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT * 
    FROM table2 
    WHERE val<100 
) table3 
ON table1.id=table3.id 

Mi pregunta es, ¿el optimizador de consultas de ser lo suficientemente inteligente para
- ejecutar la cláusula WHERE primero y luego unirse más adelante en la Declaración 1
- sepa que la tabla 3 no es realmente necesaria en la declaración 2

Soy bastante nuevo en SQL, así que por favor edúcame si no estoy entendiendo nada.

Answer 1

esto dependería de muchas muchas cosas (tamaño de la tabla, índice, la distribución de claves, etc.), sólo debe comprobar el plan de ejecución:

usted no dice qué base de datos, pero aquí hay algunas maneras:
MySql EXPLAIN
SQL Server SET SHOWPLAN_ALL (Transact-SQL)
Oracle EXPLAIN PLAN

what is explain in teradata?
Teradata Capture and compare plans faster with Visual Explain and XML plan logging

Answer 2

A menos que me falta algo, ¿Por qué incluso necesita Table1?

Sólo su búsqueda Tabla 2

Select id, val 
From table2 
WHERE val<100 

o ¿Está utilizando las filas en la Tabla 1 como un filtro? es decir, ¿Table1 solo copia un subconjunto de los Id en Table2?

Si es así, entonces esto va a funcionar tan bien ...

Select id, val 
From table2 
Where val<100 
    And id In (Select id 
       From table1) 

Pero para responder a su pregunta, sí el optimizador de consultas debe ser lo suficientemente inteligente como para averiguar el mejor orden en el que para ejecutar los pasos necesarios traducir tus instrucciones lógicas en un resultado físico. Utiliza las estadísticas almacenadas que la base de datos mantiene en cada tabla para determinar qué hacer (qué tipo de lógica de combinación usar, por ejemplo), así como en qué orden realizar las operaciones para minimizar las IO de disco y los costos de procesamiento.

Answer 3

Q1. ejecute la cláusula WHERE primero luego UNER más tarde en la instrucción 1

El problema es que si cambia el orden de unión interna, es decir table2 INNER JOIN table1, supongo que la cláusula WHERE puede procesarse antes de la operación JOIN, durante la fase de preparación .Sin embargo, supongo que incluso si no cambia la consulta original, el optimizador debería poder cambiar su orden, si cree que la operación de unión será demasiado costosa para obtener toda la fila, entonces se aplicará DONDE primero. Solo mi conjetura.

Q2. sabe que la tabla 3 no es realmente necesaria en la declaración 2

Teradata interpretará su segunda consulta de tal manera que la tabla derivada sea necesaria, por lo que seguirá procesando la operación implicada de la tabla 3.

Answer 4

Dependiendo de la disponibilidad de las estadísticas y los índices de las tablas en cuestión el mecanismo de reescritura de consultas en el optimizador puede o no optar por escanear Table2 de registros en los que val < 100 antes de escanear Table1.

En determinadas situaciones, según los datos demográficos, las uniones, la indexación y las estadísticas, es posible que el optimizador no elimine los registros en el plan de consulta cuando lo considere oportuno. Incluso si tiene una tabla derivada como la de su ejemplo. Puede obligar al optimizador a procesar una tabla derivada simplemente colocando un GROUP BY en su tabla derivada. El optimizador está obligado a resolver el agregado GROUP BY antes de considerar la posibilidad de resolver la unión entre las dos tablas en su ejemplo.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT table2.id, tabl2.val 
    FROM table2 
    WHERE val<100 
    GROUP BY 1,2 
) table3 
ON table1.id=table3.id 

Esto no quiere decir que su enfoque estándar debe ser ejecutar esto a través de su código. Este suele ser uno de mis últimos recursos cuando tengo un plan de consulta que simplemente no elimina los registros superfluos con la suficiente antelación en el plan y hace que se escaneen demasiados datos y se transporten a través de los diversos archivos SPOOL. Esta es simplemente una técnica que puede poner en su kit de herramientas cuando se encuentra con una situación de este tipo.

El mecanismo de reescritura de consultas se actualiza continuamente de una versión a la siguiente y los detalles sobre cómo funciona se pueden encontrar en el SQL Transaction Processing Manual para Teradata 13.0.