subselección vs combinación externa

Question

considerar las siguientes 2 preguntas:

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 

cual se obtienen mejores resultados? 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.

Answer 1

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 es 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.

Answer 2

Según mis observaciones, el servidor MSSQL produce el mismo plan de consulta para estas consultas.

Answer 3

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.

Answer 4

I segunda respuesta de Tom que debe elegir la que sea más fácil de comprender 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 forma de predecir cuál es más rápido es ejecutarlos contra 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.

Answer 5

La primera consulta será más rápida en SQL Server, que creo que es ligeramente intuitiva en el mostrador - Las consultas secundarias parecen como deberían ser más lentas. En algunos casos (a medida que aumentan los volúmenes de datos), un exists puede ser más rápido que un in.

Answer 6

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.

Answer 7

Cabe señalar que estas consultas producirán resultados diferentes si TblB.a no es único.

Answer 8

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, elige 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 pueden 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.

Así que, en definitiva, pruebe sus datos y compruébelo usted mismo.