SQL JOIN vs IN performance?

Question

Tengo un caso en el que usar un JOIN o un IN me dará los resultados correctos ... ¿Qué típicamente tiene un mejor rendimiento y por qué? ¿Cuánto depende de qué servidor de base de datos está ejecutando? (Para su información estoy usando MSSQL)

Answer 1

En general, IN y JOIN son consultas diferentes que pueden arrojar resultados diferentes.

SELECT a.* 
FROM a 
JOIN b 
ON  a.col = b.col 

no es lo mismo que

SELECT a.* 
FROM a 
WHERE col IN 
     (
     SELECT col 
     FROM b 
     ) 

, a menos que b.col es único.

Sin embargo, esto es sinónimo de la primera consulta:

SELECT a.* 
FROM a 
JOIN (
     SELECT DISTINCT col 
     FROM b 
     ) 
ON  b.col = a.col 

Si la columna de unión es UNIQUE y marcado como tal, tanto estas consultas dió el mismo plan en SQL Server.

Si no es así, entonces IN es más rápido que JOIN en DISTINCT.

Lee este artículo en mi blog para los detalles de rendimiento:

• IN vs. JOIN vs. EXISTS

Answer 2

Eso es bastante difícil de decir, para averiguar realmente cuál funciona mejor, necesita un perfil real de los tiempos de ejecución.

Como regla general, creo que si tiene índices en sus columnas de clave externa, y si usa solo (o principalmente) condiciones de UNIÓN INTERNA, entonces el JOIN será un poco más rápido.

Pero tan pronto como empiece a usar OUTER JOIN, o si no tiene índices de clave externa, la IN podría ser más rápida.

Marc

Answer 3

curioso que mencionar que, hice un post sobre este mismo tema.

Ver respuesta Oracle vs MySQL vs SQL Server: Aggregation vs Joins

corta: hay que probarlo y bases de datos individuales varían mucho.

Answer 4

El optimizador debe ser lo suficientemente inteligente como para ofrecer el mismo resultado en cualquier caso para las consultas normales. Verifica el plan de ejecución y ellos deberían darte lo mismo. Si no lo hacen, normalmente consideraría que JOIN es más rápido. Sin embargo, todos los sistemas son diferentes, por lo que debe crear un perfil del código en su sistema para estar seguro.

Answer 5

La implementación de cada base de datos, pero probablemente puedas adivinar que todas resuelven problemas comunes más o menos de la misma manera. Si está utilizando MSSQL eche un vistazo al plan de ejecución que se genera. Puede hacer esto al encender los planes de perfilador y ejecuciones. Esto le dará una versión de texto cuando ejecute el comando.

No estoy seguro de qué versión de MSSQL está utilizando pero puede obtener una gráfica en SQL Server 2000 en el analizador de consultas. Estoy seguro de que esta funcionalidad se esconde en SQL Server Studio Manager en versiones posteriores.

Eche un vistazo al plan de exención. En la medida de lo posible, evite los escaneos de tabla a menos que, por supuesto, su tabla sea pequeña, en cuyo caso un escaneo de tabla es más rápido que usar un índice. Lea sobre las diferentes operaciones de unión que produce cada escenario diferente.

Answer 6

Una valoración crítica interesante sobre las diferencias lógicas: SQL Server: JOIN vs IN vs EXISTS - the logical difference

estoy bastante seguro de que si se asume que las relaciones y los índices se mantienen. Unir tendrá un mejor rendimiento en general (se requiere más esfuerzo para trabajar con esa operación que otros). Si lo piensas conceptualmente, entonces es la diferencia entre 2 consultas y 1 consulta.

Debe conectarlo al Analizador de consultas y probarlo para ver la diferencia. Consulte también el Plan de ejecución de consultas y trate de minimizar los pasos.

Answer 7

Este subproceso es bastante antiguo, pero todavía se menciona con frecuencia. Para mi gusto personal, es un poco incompleto, porque hay otra manera de preguntar a la base de datos con la palabra clave EXISTS que me pareció más rápida que nunca.

Así que si usted está interesado sólo en los valores de la Tabla A se puede utilizar esta consulta:

SELECT a.* 
FROM a 
WHERE EXISTS (
    SELECT * 
    FROM b 
    WHERE b.col = a.col 
    ) 

La diferencia puede ser enorme si col no está indexado, porque el PP no tiene que buscar todos los registros en b que tienen el mismo valor en col, solo tiene que encontrar el primero. Si no hay un índice en b.col y muchos registros en b, la consecuencia podría ser un escaneo de tabla. Con IN o un JOIN esto sería un escaneo de tabla completo, con EXISTS esto sería solo un escaneo de tabla parcial (hasta que se encuentre el primer registro coincidente).

Si hay un montón de registros en b que tienen el mismo valor col, también perderá mucha memoria para leer todos estos registros en un espacio temporal solo para encontrar que su condición está satisfecha. Con existe esto generalmente se puede evitar.

A menudo he encontrado EXISTS más rápido que EN, incluso si hay un índice. Depende del sistema de base de datos (el optimizador), los datos y, por último, no menos importante del tipo de índice que se utiliza.