Esta é uma resposta independente de RDBMS, mas pode ajudar no entanto. No meu entendimento, a subconsulta correlacionada (também conhecida como dependente) é talvez a culpada mais frequentemente falsamente acusada de mau desempenho.

O problema (como é descrito com mais frequência) é que ele processa a consulta interna para cada linha da consulta externa. Portanto, se a consulta externa retornar 1.000 linhas e a consulta interna retornar 10.000, sua consulta terá que percorrer 10.000.000 linhas (externas × internas) para produzir um resultado. Em comparação com as 11.000 linhas (externas + internas) de uma consulta não correlacionada nos mesmos conjuntos de resultados, isso não é bom.

No entanto, este é apenas o pior cenário. Em muitos casos, o DBMS poderá explorar índices para reduzir drasticamente a contagem de linhas. Mesmo que apenas a consulta interna possa usar um índice, as 10.000 linhas se tornam ~13 buscas, o que reduz o total para 13.000.

O exists O operador pode interromper o processamento de linhas após a primeira, reduzindo ainda mais o custo da consulta, especialmente quando a maioria das linhas externas corresponde a pelo menos uma linha interna.

Em alguns casos raros, vi o SQL Server 2008R2 otimizar subconsultas correlacionadas para uma junção de mesclagem (que percorre os dois conjuntos apenas uma vez - melhor cenário possível) onde um índice adequado pode ser encontrado em consultas internas e externas.

O verdadeiro culpado pelo mau desempenho não são necessariamente as subconsultas correlacionadas , mas verificações aninhadas .