not - Combinaciones explícitas vs implícitas de SQL

sql like multiple values

Question

¿Hay alguna diferencia de eficiencia en una unión interna explícita vs implícita? Por ejemplo:

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

contra

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), pero tenga en cuenta que están desaprobando esta sintaxis de unión y no es compatible con SQL Server2005 de forma inmediata.

Creo que estás pensando en los operadores desaprobados * = y = * frente a la "combinación externa".

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

Answer 2

@lomaxx: Solo para aclarar, estoy bastante seguro de que ambas sintaxis anteriores son compatibles con SQL Serv 2005. Sin embargo, la sintaxis a continuación NO es compatible

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

Específicamente, la unión externa (* =) no es compatible.

Answer 3

Como ha indicado Leigh Caldwell, el optimizador de consultas puede producir diferentes planes de consulta según 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 te resulte interesante.

Answer 4

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)

tabla1 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 confunda y genere planes diferentes en un caso más complicado.

Answer 5

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

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

Answer 6

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 las tablas en la cláusula from y no desordena la cláusula where.

Answer 7

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

PD: Tenga en cuenta que la sintaxis de IMPLICIT OUTER JOIN está en desuso desde SQL Server 2005. (La sintaxis de IMPLICIT INNER JOIN que se usa en la pregunta aún es compatible)

Desaprobación de la sintaxis de "estilo antiguo" de JOIN: sólo una cosa parcial

Answer 8

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ño cerebral, especialmente si está utilizando un producto Microsoft SQL. La forma en que SQL Server intenta estimar los recuentos de filas de la tabla, por ejemplo, es tremendamente horrible. El uso de la sintaxis de unión interna le proporciona 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 base de datos actual, tiene que ir con la unión interna.

Answer 9

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ía usar la sintaxis de unión ANSI. Como decían, la razón principal es la claridad. En lugar de tener una cláusula where con muchos predicados, algunos de los cuales se unen a las tablas y otros restringen las filas devueltas con la sintaxis de la unión ANSI, lo que deja en claro las condiciones que se usan para unirlas y las que se usan para restringir resultados

Answer 10

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

Answer 11

Personalmente, prefiero la sintaxis de unión, ya que hace que sea más claro que las tablas están unidas y cómo se unen. Intente comparar consultas SQL más grandes en las que selecciona de 8 tablas diferentes y tiene muchos filtros en el lugar. Al usar la sintaxis de unión, se separan las partes donde se unen las tablas, a la parte donde se filtran las filas.