En el caso de un INNER JOIN o una tabla a la izquierda en LEFT JOIN, en muchos casos, el optimizador encontrará que es mejor realizar cualquier filtrado primero (selectividad más alta) antes de realizar cualquier tipo de unión física, por lo que hay son obviamente órdenes físicos de operaciones que son mejores.
Hasta cierto punto, a veces puede controlar esto (o interferir con esto) con su SQL, por ejemplo, con agregados en subconsultas.
El orden lógico de procesamiento de las restricciones en la consulta solo se puede transformar de acuerdo con transformaciones invariantes conocidas.
Entonces:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
sigue siendo lógicamente equivalente a:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
y generalmente tendrán el mismo plan de ejecución.
Por otro lado:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
NO es equivalente a:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
por lo que el optimizador no los va a transformar en el mismo plan de ejecución.
El optimizador es muy inteligente y puede mover las cosas con bastante éxito, incluidas las vistas colapsadas y las funciones con valores de tabla en línea, así como incluso empujar las cosas hacia abajo a través de ciertos tipos de agregados con bastante éxito.
Por lo general, cuando escribe SQL, debe ser comprensible, mantenible y correcto. En cuanto a la eficiencia en la ejecución, si el optimizador tiene dificultades para convertir el SQL declarativo en un plan de ejecución con un rendimiento aceptable, a veces se puede simplificar el código o se pueden agregar índices o sugerencias apropiados o dividirlos en pasos que deberían actuar más rápidamente, todo en órdenes sucesivos de invasividad.
