sql - example - subselección vs unión externa
union all oracle pl sql (8)
Considere las siguientes 2 consultas:
select tblA.a,tblA.b,tblA.c,tblA.d
from tblA
where tblA.a not in (select tblB.a from tblB)
select tblA.a,tblA.b,tblA.c,tblA.d
from tblA left outer join tblB
on tblA.a = tblB.a where tblB.a is null
¿Cuál funcionará mejor? Mi suposición es que, en general, la combinación será mejor, excepto en los casos en que la subselección arroje un conjunto de resultados muy pequeño.
subconsultas no correlacionadas están bien. debe ir con lo que describe los datos que quiere. como se ha notado, esto probablemente se reescribe en el mismo plan, ¡pero no se garantiza! Además, si las tablas A y B no son 1: 1 obtendrás tuplas duplicadas de la consulta de combinación (ya que la cláusula IN realiza una clasificación DISTINCT implícita), por lo que siempre es mejor codificar lo que deseas y pensar realmente en el resultado.
Creé una consulta simple similar a las de la pregunta en MSSQL2005 y los planes de explicación fueron diferentes. La primera consulta parece ser más rápida. No soy un experto en SQL pero el plan de explicación estimado tenía un 37% para la consulta 1 y un 63% para la consulta 2. Parece que el mayor costo para la consulta 2 es la unión. Ambas consultas tenían dos escaneos de tabla.
Según mis observaciones, el servidor MSSQL produce el mismo plan de consulta para estas consultas.
En segundo lugar, la respuesta de Tom es que debes escoger la que sea más fácil de entender y mantener.
El plan de consulta de cualquier consulta en cualquier base de datos no puede predecirse porque no nos ha proporcionado índices o distribuciones de datos. La única manera de predecir cuál es más rápido es ejecutarlos en su base de datos.
Como regla general, suelo usar sub-selecciones cuando no necesito incluir ninguna columna de tblB en mi cláusula de selección. Definitivamente iré por una sub-selección cuando quiero usar el predicado ''in'' (y generalmente para el ''no en'' que incluyó en la pregunta), por la simple razón de que estos son más fáciles de entender cuando usted o alguien más ha vuelto y los cambia.
La primera consulta será más rápida en SQL Server, lo que creo que es ligeramente intuitivo: las consultas secundarias parecen ser más lentas. En algunos casos (a medida que aumentan los volúmenes de datos), una exists puede ser más rápida que una entrada.
Cabe señalar que estas consultas producirán resultados diferentes si TblB.a no es único.
Bueno, depende de los conjuntos de datos. Desde mi experiencia, si tienes un pequeño conjunto de datos, entonces busca un NOT IN si es grande para un IZQUIERDO. La cláusula NOT IN parece ser muy lenta en grandes conjuntos de datos.
Otra cosa que podría agregar es que los planes de explicación podrían ser engañosos. He visto varias consultas donde Explain estaba muy alto y la consulta se ejecuta en 1s. Por otro lado, he visto consultas con un excelente plan de explicación y podrían funcionar durante horas.
Entonces, en general, pruebe sus datos y compruébelo usted mismo.
RDBMS "reescribe" consultas para optimizarlas, por lo que depende del sistema que está utilizando, y supongo que terminan dando el mismo rendimiento en la mayoría de las bases de datos "buenas".
Sugiero elegir el que sea más claro y fácil de mantener, por mi dinero, ese es el primero. Es mucho más fácil depurar la subconsulta, ya que se puede ejecutar de forma independiente para comprobar la cordura.