Uniones SQL explícitas e implícitas

Question

¿Existe alguna diferencia de eficiencia entre una unión interna explícita e implícita?Por ejemplo:

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

vs.

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

Answer 1

En cuanto al rendimiento, son exactamente iguales (al menos en SQL Server).

PD:Tenga en cuenta que el IMPLICIT OUTER JOIN La sintaxis está en desuso desde SQL Server 2005.(El IMPLICIT INNER JOIN la sintaxis utilizada en la pregunta todavía es compatible)

Desuso de la sintaxis JOIN del "estilo antiguo":Sólo una cosa parcial

Answer 2

Personalmente prefiero la sintaxis de unión porque deja más claro que las tablas están unidas y cómo se unen.Intente comparar consultas SQL más grandes donde seleccione entre 8 tablas diferentes y tenga muchos filtros en el dónde.Al utilizar la sintaxis de unión, separa las partes donde se unen las tablas hasta la parte donde filtra las filas.

Answer 3

En MySQL 5.1.51, ambas consultas tienen planes de ejecución idénticos:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1 tiene 166208 filas; table2 tiene alrededor de 1000 filas.

Este es un caso muy simple;de ninguna manera prueba que el optimizador de consultas no se confundiría y generaría planes diferentes en un caso más complicado.

Answer 4

La segunda sintaxis tiene la posibilidad no deseada de una unión cruzada:puede agregar tablas a la parte FROM sin la cláusula WHERE correspondiente.Esto se considera perjudicial.

Answer 5

La primera respuesta que dio utiliza lo que se conoce como sintaxis de unión ANSI, la otra es válida y funcionará en cualquier base de datos relacional.

Estoy de acuerdo con grom en que deberías usar la sintaxis de unión ANSI.Como dijeron, la razón principal es la claridad.En lugar de tener una cláusula donde con muchos predicados, algunos de los cuales unen tablas y otros restringen las filas devueltas con la sintaxis de unión ANSI, está dejando absolutamente claro qué condiciones se utilizan para unir sus tablas y cuáles se utilizan para restringir la resultados.

Answer 6

@lomaxx:Sólo para aclarar, estoy bastante seguro de que las dos sintaxis anteriores son compatibles con SQL Serv 2005.Sin embargo, la siguiente sintaxis NO es compatible

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

Específicamente, no se admite la unión externa (*=).

Answer 7

En cuanto al rendimiento, son exactamente iguales (al menos en SQL Server), pero tenga en cuenta que están desaprobando esta sintaxis de unión y que SQL Server2005 no la admite de fábrica.

Creo que estás pensando en los operadores obsoletos *= y =* vs."unión externa".

Acabo de probar los dos formatos proporcionados y funcionan correctamente en una base de datos SQL Server 2008.En mi caso, arrojaron planes de ejecución idénticos, pero no podía decir con seguridad que esto sería siempre así.

Answer 8

En algunas bases de datos (especialmente Oracle), el orden de las uniones puede marcar una gran diferencia en el rendimiento de las consultas (si hay más de dos tablas).En una aplicación, tuvimos literalmente dos órdenes de magnitud de diferencia en algunos casos.El uso de la sintaxis de unión interna le brinda control sobre esto, si usa la sintaxis de sugerencias correcta.

No especificó qué base de datos está utilizando, pero la probabilidad sugiere SQL Server o MySQL, donde no hay ninguna diferencia real.

Answer 9

Como ha declarado Leigh Caldwell, el optimizador de consultas puede producir diferentes planes de consulta basados ​​en lo que funcionalmente parece la misma declaración SQL.Para leer más sobre esto, eche un vistazo a las siguientes dos publicaciones de blog: -

Una publicación del equipo de Oracle Optimizer

Otra publicación del blog "Datos Estructurados"

Espero que encuentres esto interesante.

Answer 10

En cuanto al rendimiento, no debería hacer ninguna diferencia.La sintaxis de unión explícita me parece más clara ya que define claramente las relaciones entre tablas en la cláusula from y no satura la cláusula where.

Answer 11

En mi experiencia, el uso de la sintaxis de unión cruzada con una cláusula donde a menudo produce un plan de ejecución con daños cerebrales, especialmente si está utilizando un producto de Microsoft SQL.La forma en que SQL Server intenta estimar el número de filas de una tabla, por ejemplo, es tremendamente horrible.El uso de la sintaxis de unión interna le brinda cierto control sobre cómo se ejecuta la consulta.Entonces, desde un punto de vista práctico, dada la naturaleza atávica de la tecnología de bases de datos actual, hay que optar por la unión interna.

Answer 12

Básicamente, la diferencia entre los dos es que uno está escrito en la forma antigua, mientras que el otro está escrito en la forma moderna.Personalmente, prefiero el script moderno que utiliza las definiciones interior, izquierda, exterior y derecha porque son más explicativas y hacen que el código sea más legible.

Cuando se trata de uniones internas tampoco hay una diferencia real en la legibilidad; sin embargo, puede resultar complicado cuando se trata de uniones izquierda y derecha, ya que en el método anterior obtendría algo como esto:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

Lo anterior es la forma antigua en la que se escribe una unión izquierda, a diferencia de lo siguiente:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

Como puede ver visualmente, la forma moderna de escribir el guión hace que la consulta sea más legible.(Por cierto, lo mismo ocurre con las uniones derechas y un poco más complicado para las uniones externas).

Volviendo a lo básico, al compilador SQL no le importa cómo se escribe la consulta, ya que las maneja de la misma manera.He visto una combinación de ambos en las bases de datos de Oracle en las que muchas personas han escrito, tanto mayores como más jóvenes.Nuevamente, todo se reduce a qué tan legible sea el guión y al equipo con el que lo estés desarrollando.