¿Hay algún problema de rendimiento al usar la palabra clave "IN" en las declaraciones SQL en lugares donde podemos usar JOIN?Usando 'IN' con una subconsulta en las declaraciones SQL
SELECT xxx
FROM xxx
WHERE ID IN (SELECT Id FROM xxx)
No, está bien usar.
Puede escribir la consulta anterior utilizando IN, EXISTS en todos los RDBMS, algunos también admiten INTERSECT.
Semánticamente esta es una semi unión que "me da filas de la tabla A donde tengo al menos una coincidencia en la tabla B". Una unión interior es "dame todas las filas coincidentes"
Así que si TableA tiene 3 filas y TableB tiene 5 filas que coinciden con:
por eso, en y que existe son empujados por mí y los otros tipos SQL aquí: una combinación es incorrecta, requiere distintos y serán más lentas.
EXISTS admiten varias columnas JOINs, IN no en SQL Server (lo hace en otras).
Como se puede leer here, se une son más rápidos que los sub-selecciona.
En lugar de un grupo distinto, puede usar group by. He tenido casos en los que obtuve un mejor tiempo de respuesta al usar join. Normalmente, cuando me estoy uniendo a todas las filas a través de una clave principal/relación de clave externa y donde está buscando una columna no clave. Especialmente si se une múltiples. El IN puede A VECES forzar un escaneo de índice y la unión TÍPICAMENTE usará una búsqueda si va al PK. Cuando diseñe sus tablas, alinee las claves principales para que estén en el mismo orden y declare explícitamente las relaciones PK/FK. Unirse NO está limitado a PK/FK. Pero el uso común de una unión es realizar una relación PK/FK y, en ese caso, mi mejor experiencia es utilizar una combinación con las teclas alineadas.
No está bien usarlo. Ver mi respuesta –
@ T-clausen.dk: Tengo, estás equivocado – gbn
Sí, estoy equivocado. Estaba tratando de demostrar que tenía razón al hacerte un ejemplo. Sin embargo, el ejemplo mostró que estaba equivocado. Me disculpo y eliminé mi respuesta. –