Entonces, IN no es lo mismo que EXISTS ni producirá el mismo plan de ejecución.
Por lo general, EXISTS se usa en una subconsulta correlacionada, lo que significa que UNIRÁ la consulta interna EXISTS con su consulta externa. Eso agregará más pasos para producir un resultado, ya que necesita resolver las uniones de consultas externas y las uniones de consultas internas luego coinciden con sus cláusulas where para unir ambas.
Por lo general, IN se usa sin correlacionar la consulta interna con la consulta externa, y eso se puede resolver en un solo paso (en el mejor de los casos).
Considera esto:
Si usa IN y el resultado de la consulta interna son millones de filas de valores distintos, probablemente funcionará MÁS LENTO que EXISTS dado que la consulta EXISTS funciona correctamente (tiene los índices correctos para unirse con la consulta externa).
Si usa EXISTS y la combinación con su consulta externa es compleja (lleva más tiempo realizarla, no hay índices adecuados), la consulta se ralentizará según el número de filas en la tabla externa; a veces, el tiempo estimado para completar puede ser en días. Si el número de filas es aceptable para su hardware dado, o la cardinalidad de los datos es correcta (por ejemplo, menos valores DISTINCT en un conjunto de datos grande), IN puede funcionar más rápido que EXISTS.
Todo lo anterior se notará cuando tenga una buena cantidad de filas en cada tabla (por justo me refiero a algo que excede el procesamiento de su CPU y / o los umbrales de RAM para el almacenamiento en caché).
Entonces la RESPUESTA es DEPENDE. Puede escribir una consulta compleja dentro de IN o EXISTS, pero como regla general, debe intentar usar IN con un conjunto limitado de valores distintos y EXISTS cuando tenga muchas filas con muchos valores distintos.
El truco consiste en limitar el número de filas a escanear.
Saludos,
MarianoC