Anidados INNER JOIN vs INNER JOIN vs WHERE: corrección, rendimiento, claridad para un caso particular (no es un problema típico de JOIN vs WHERE)

Question

Estoy estudiando inner joins y soy un hombre WHERE SQL-92. Me gustaría saber las implicaciones y entender cómo funciona. Así que esta es solo una pregunta teórica sobre SQL se une. es esto ...

SELECT * FROM -- Query 1 
tbl1 
INNER JOIN (
      tbl2 
      INNER JOIN (
      tbl3 INNER JOIN tbl4 ON tbl3.Col1 = tbl4.Col1 
     ) 
      ON tbl2.col1 = tbl3.col2 
) 
ON tbl1.col1 = tbl3.col3 

... lo mismo que esto?

SELECT * FROM -- Query 2 
tbl3 
INNER JOIN tbl4 ON tbl3.col1 = tbl4.col1 
INNER JOIN tbl2 ON tbl2.col1 = tbl3.col2 
INNER JOIN tbl1 ON tbl1.col1 = tbl3.col3 

... o esto (no ordenado por resolución lógica)?

SELECT * FROM -- Query 3 
    tbl3 
    INNER JOIN tbl1 ON tbl1.col1 = tbl3.col3 
    INNER JOIN tbl2 ON tbl2.col1 = tbl3.col2 
    INNER JOIN tbl4 ON tbl3.col1 = tbl4.col1 

..o este (nodo de referencia cambió; ver que hay una tabla de referencia antes de que se cita, pero el producto cartesiano debería ser el mismo)

SELECT * FROM -- Query 4 
    tbl4 
    INNER JOIN tbl1 ON tbl1.col1 = tbl3.col3 
    INNER JOIN tbl2 ON tbl2.col1 = tbl3.col2 
    INNER JOIN tbl3 ON tbl4.col1 = tbl3.col1 

..o esto?

SELECT * FROM -- Query 5 
    tbl1,tbl2,tbl3,tbl4 
    WHERE 
    tbl3.col1 = tbl4.col1 
    tbl2.col1 = tbl3.col2 
    tbl1.col1 = tbl3.col3 

... ¿desde puntos de vista estéticos, sintácticos, mejores prácticas y funcionales?

¡Es una pregunta muy abierta, pero creo que es muy interesante para la comunidad arrojar algo de luz!

Answer 1

Todos los motores de bases de datos que he estado trabajando estrechamente con (esto es SQL Server, Oracle, PostgreSQL, MySQL, Sybase, SQLite, Informix y Firebird) optimizará al mismo plan.

La cuarta consulta, sin embargo, no se analizará en todos los motores (no se puede hacer referencia a una tabla en una cláusula de ON antes de que se había utilizado en una cláusula JOIN)

MySQL ofrece STRAIGHT_JOIN cláusula que afecta el orden de combinación usado en el plan.

En Oracle, hay una pista /*+ ORDERED */ y en SQL Server hay una pista similar FORCE ORDER. Si una consulta utiliza estas sugerencias, la orden de planificación también se verá afectada por la orden de unión.

Answer 2

Desde el punto de vista de la corrección, es probable que sean iguales. Desde el punto de vista del rendimiento, depende del RDBMS (solo puedo hablar de SQL Server, donde todas las variantes producirán el mismo plan de ejecución).

Answer 3

¡En Sybase también tendrán el mismo plan de ejecución! El optimizador de consultas es lo suficientemente inteligente como para crear el mismo plan de ejecución para todos :)

Podría cambiar internamente la consulta para seleccionar primero la tabla más pequeña y hacer las combinaciones internas con esa.

Respecto al uso de la unión interna o la unión anidada (la última), prefiero la primera. Es más legible tener las uniones internas con las conexiones entre las tablas y luego, si es necesario, una cláusula where con las restricciones (en tu ejemplo, no tienes estas restricciones).