Esta es una respuesta independiente de RDBMS, pero puede ayudar de todos modos. Según tengo entendido, la subconsulta correlacionada (también conocida como dependiente) es quizás el culpable acusado falsamente con mayor frecuencia de un mal rendimiento.
El problema (como suele describirse) es que procesa la consulta interna para cada fila de la consulta externa. Por lo tanto, si la consulta externa devuelve 1,000 filas y la consulta interna devuelve 10,000, entonces su consulta debe recorrer 10,000,000 filas (externa × interna) para producir un resultado. En comparación con las 11 000 filas (externas+internas) de una consulta no correlacionada sobre los mismos conjuntos de resultados, eso no es bueno.
Sin embargo, este es solo el peor de los casos. En muchos casos, el DBMS podrá explotar los índices para reducir drásticamente el número de filas. Incluso si solo la consulta interna puede usar un índice, las 10 000 filas se convierten en ~13 búsquedas, lo que reduce el total a 13 000.
El exists el operador puede dejar de procesar filas después de la primera, lo que reduce aún más el costo de la consulta, especialmente cuando la mayoría de las filas externas coinciden con al menos una fila interna.
En algunos casos raros, he visto a SQL Server 2008R2 optimizar las subconsultas correlacionadas a una unión de fusión (que atraviesa ambos conjuntos solo una vez, el mejor escenario posible) donde se puede encontrar un índice adecuado en las consultas internas y externas.
El verdadero culpable del mal rendimiento no son necesariamente las subconsultas correlacionadas , pero escaneos anidados .
