sql - tuning - Unirse interior vs Donde
tuning oracle sql queries (18)
¿Hay alguna diferencia en el rendimiento (en oráculo) entre
Select * from Table1 T1
Inner Join Table2 T2 On T1.ID = T2.ID
Y
Select * from Table1 T1, Table2 T2
Where T1.ID = T2.ID
?
¡No! El mismo plan de ejecución, mira estas dos tablas:
CREATE TABLE table1 (
id INT,
name VARCHAR(20)
);
CREATE TABLE table2 (
id INT,
name VARCHAR(20)
);
El plan de ejecución de la consulta mediante la unión interna:
-- with inner join
EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
Y el plan de ejecución para la consulta utilizando una cláusula WHERE.
-- with where clause
EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
Ambas son combinaciones internas que hacen lo mismo, una simplemente usa la sintaxis ANSI más nueva.
Aunque la identidad de dos consultas parece obvia a veces suceden algunas cosas extrañas. He accedido a la consulta que tiene diferentes planes de ejecución al mover el predicado de la combinación de UNIR a DÓNDE en Oracle 10g (para DÓNDE el plan es mejor), pero no puedo reproducir este problema en tablas y datos simplificados. Creo que depende de mis datos y estadísticas. El optimizador es un módulo bastante complejo y en ocasiones se comporta mágicamente.
Es por eso que no podemos responder a esta pregunta en general porque depende de los datos internos de DB. Pero debemos saber que la respuesta tiene que ser " sin diferencias ".
Como dijo kiewik, el plan de ejecución es el mismo.
La declaración de JOIN es solo más fácil de leer, por lo que es más fácil no olvidar la condición ON y obtener un producto cartesiano. Estos errores pueden ser bastante difíciles de detectar en consultas largas que utilizan varias combinaciones de tipo: SELECT * FROM t1, t2 WHERE t1.id = t2.some_field.
Si olvida solo una condición de unión, obtiene una consulta muy larga para devolver demasiados registros ... realmente demasiados. Algunas personas usan DISTINCT para parchear la consulta, pero aún es muy largo de ejecutar.
Eso es precisamente el motivo por el que usar la declaración JOIN es sin duda la mejor práctica: una mejor capacidad de mantenimiento y una mejor legibilidad.
Además, si recuerdo bien, JOIN está optimizado en relación con el uso de la memoria.
Deben ser exactamente iguales. Sin embargo, como práctica de codificación, prefiero ver la unión. Claramente articula su intención,
El rendimiento debería ser idéntico, pero sugeriría usar la versión de combinación debido a una mayor claridad cuando se trata de uniones externas.
También se pueden evitar los productos cartesianos no intencionales utilizando la versión conjunta.
Un tercer efecto es un SQL más fácil de leer con una condición WHERE más simple.
En PostgreSQL, definitivamente no hay diferencia, ambos equivalen al mismo plan de consulta. Estoy 99% seguro de que también es el caso de Oracle.
En un escenario en el que las tablas se encuentran en la 3ª forma normal, las uniones entre tablas no deberían cambiar. Es decir, unirse a CLIENTES y PAGOS siempre deben seguir siendo los mismos.
Sin embargo debemos distinguir las uniones de los filtros . Las uniones son sobre relaciones y los filtros son sobre la partición de un todo.
La sintaxis SQL-92 nos alienta a separar ambos conceptos y es preferible a la sintaxis antigua que pone ambas, combinaciones y filtros, en la cláusula WHERE, que es más engorrosa.
Es cierto que, funcionalmente, ambas consultas deben procesarse de la misma manera. Sin embargo, la experiencia ha demostrado que si está seleccionando vistas que usan la nueva sintaxis de unión, es importante estructurar sus consultas también. El optimizador de Oracle puede confundirse si una vista usa una declaración de "unión", pero una consulta que accede a la vista usa el método tradicional de unirse en la cláusula "where".
Funcionalmente son los mismos que se han dicho. Sin embargo, estoy de acuerdo en que hacer la unión es mejor para describir exactamente lo que quieres hacer. Muchas veces he pensado que sabía cómo quería consultar algo hasta que empecé a hacer las uniones y me di cuenta de que quería hacer una consulta diferente a la original en mi cabeza.
No olvide que en Oracle, siempre que los atributos de la clave de unión tengan el mismo nombre en ambas tablas, también puede escribir esto como:
select *
from Table1 inner join Table2 using (ID);
Esto también tiene el mismo plan de consulta, por supuesto.
No sé sobre Oracle, pero sé que la antigua sintaxis está en desuso en SQL Server y desaparecerá con el tiempo. Antes de usar esa antigua sintaxis en una nueva consulta, comprobaría qué planes tiene Oracle de hacer con ella.
Prefiero la sintaxis más nueva en lugar de la mezcla de los criterios de unión con otras condiciones necesarias. En la nueva sintaxis es mucho más claro qué crea la unión y qué otras condiciones se aplican. No es realmente un gran problema en una consulta corta como esta, pero se vuelve mucho más confuso cuando tienes una consulta más compleja. Como las personas aprenden sobre las consultas básicas, yo tendería a preferir que las personas aprendan a usar la sintaxis de unión antes de que la necesiten en una consulta compleja.
Y nuevamente no conozco específicamente a Oracle, pero sé que la versión de SQL Server de la combinación izquierda de estilo antiguo es defectuosa incluso en SQL Server 2000 y da resultados inconsistentes (a veces una combinación de izquierda a veces es una combinación cruzada), por lo que nunca debería ser usado. Esperemos que Oracle no sufra el mismo problema, pero ciertamente las uniones de izquierda y derecha pueden ser más difíciles de expresar correctamente en la sintaxis anterior.
Además, según mi experiencia (y, por supuesto, esta es una opinión estrictamente personal, es posible que tenga una experiencia diferente), los desarrolladores que utilizan las uniones ANSII tienden a comprender mejor qué es una unión y qué significa en términos de obtener Datos fuera de la base de datos. Creo que esto se debe a que la mayoría de las personas con un buen conocimiento de la base de datos tienden a escribir consultas más complejas, y me parece que es mucho más fácil mantenerlas utilizando el estándar ANSII que el estilo antiguo.
Si el optimizador de consultas está haciendo su trabajo correctamente, no debería haber diferencia entre esas consultas. Son solo dos formas de especificar el mismo resultado deseado.
Son lógicamente idénticos, pero en las versiones anteriores de Oracle que adoptaban la sintaxis ANSI, a menudo había errores en los casos más complejos, por lo que a veces encontrará resistencia por parte de los desarrolladores de Oracle cuando la usan.
Son las dos juntas y donde hacen lo mismo.
Dé un vistazo a las consultas en MySQL, ¿por qué usar join en lugar de dónde?
Tuve este dilema hoy al inspeccionar uno de los tiempos de nuestro SP en producción, cambié una combinación interna en una tabla creada desde un feed XML a una cláusula ''where'' en su lugar ... el tiempo de ejecución promedio es ahora de 80 ms en 1000 ejecuciones, mientras que antes de que el promedio de ejecución fuera de 2.2 segundos ... la diferencia principal en el plan de ejecución es la desaparición de una búsqueda de clave ... El mensaje es que no sabrá hasta que haya probado utilizando ambos métodos.
aclamaciones.
Usar JOIN hace que el código sea más fácil de leer, ya que se explica por sí mismo.
No hay diferencia en la velocidad ( acabo de probarlo ) y el plan de ejecución es el mismo.
[Para un punto de bonificación ...]
El uso de la sintaxis de JOIN le permite comentar más fácilmente la unión ya que está todo incluido en una línea. Esto puede ser útil si está depurando una consulta compleja
Como todos los demás dicen, son funcionalmente iguales, sin embargo, JOIN es más claro que una declaración de intenciones. Por lo tanto, puede ayudar al optimizador de consultas en las versiones actuales de Oracle en ciertos casos (no tengo idea si lo hace), puede ayudar al optimizador de consultas en futuras versiones de Oracle (nadie tiene idea), o puede ayudar si cambia proveedor de base de datos.