Diferencias entre EXISTS e IN en SQL
Un problema persistente en el uso de SQL consiste en determinar el uso adecuado de los operadores EXISTS e IN. Los dos operadores pueden producir los mismos resultados, pero no siempre lo hacen. También existe un debate considerable sobre cómo es optimizado cada operador para ser veloz. Los usuarios deben entender los diferentes atributos de cada operador y probar ambos para determinar la función adecuada.
Operador IN
El operador IN devuelve una fila si un valor de tabla.campo condicionado WHERE coincide con una lista de valores IN. IN se utiliza normalmente como parte de una consulta principal o junto con una subconsulta. Ejemplo 1: WHERE Tabla.Campo en ('a', 'b', 'c') Ejemplo 2: WHERE Tabla.Campo en (conjunto de valores devueltos por la subconsulta)
Operador EXISTS
El operador EXISTS devuelve todas las principales líneas de consulta si la subconsulta contiene alguna fila. EXISTS sólo se utiliza en conjunción con una subconsulta. Las filas devueltas se determinan mediante el filtrado a nivel de consulta principal. Ejemplo: WHERE EXISTS (conjunto de valores de retorno de la subconsulta)
Diferencia
IN no puede evaluar NULLs, por lo que las filas son siempre falsas, y no se devuelven. EXISTS puede evaluar NULL, por lo que las filas se pueden devolver.
Similitudes
EXISTE e IN ambos soportan subconsultas correlacionadas y no correlacionadas, y ambos pueden producir resultados principales similares. Cuando están correlacionados, EXISTS e IN hacen coincidir un campo principal de consulta con un campo de subconsulta (ex: main.id = subquery.id). La subconsulta se evalúa fila por fila, para cada coincidencia encontrada. En este caso, IN y EXISTS devolverán las mismas filas en función de las identificaciones similares. Cuando no están correlacionados, EXISTE e IN procesan sus subconsultas primero y luego hacen coincidir los resultados con la consulta principal.
Desempeño de EXISTS e IN
El rendimiento se determina por el optimizador de la base de datos y el plan de ejecución que emplea para el código que se ejecuta. Para EXISTS e IN, el optimizador puede elegir diferentes caminos. En Oracle, NO EXISTS evita un anti-join, y por lo general demuestra ser más rápido que NO IN. En definitiva, se requiere un poco de ensayo y error para determinar el camino más rápido dependiendo de la base de datos y su versión en uso. Asegúrate de utilizar el operador que garantice los resultados correctos, si toda da lo mismo, intenta sustituir EXISTS e IN para ver realmente cuál es más rápido.