Jest to odpowiedź niezależna od RDBMS, ale mimo to może pomóc. W moim rozumieniu skorelowane (czyli zależne) podzapytanie jest prawdopodobnie najczęściej fałszywie oskarżanym winowajcą złej wydajności.
Problem (jak to jest najczęściej opisywane) polega na tym, że przetwarza wewnętrzne zapytanie dla każdego wiersza zapytania zewnętrznego. Dlatego jeśli zapytanie zewnętrzne zwraca 1000 wierszy, a zapytanie wewnętrzne 10 000, to zapytanie musi przejść przez 10 000 000 wierszy (zewnętrzne×wewnętrzne), aby uzyskać wynik. W porównaniu z 11 000 wierszy (zewnętrzne + wewnętrzne) z nieskorelowanego zapytania w tych samych zestawach wyników, to nie jest dobre.
To jednak tylko najgorszy scenariusz. W wielu przypadkach DBMS będzie w stanie wykorzystać indeksy, aby drastycznie zmniejszyć liczbę wierszy. Nawet jeśli tylko wewnętrzne zapytanie może używać indeksu, 10 000 wierszy staje się ~ 13 wyszukiwań, co zmniejsza sumę do 13 000.
exists operator może zatrzymać przetwarzanie wierszy po pierwszym, co dodatkowo zmniejsza koszt zapytania, zwłaszcza gdy większość wierszy zewnętrznych pasuje do co najmniej jednego wiersza wewnętrznego.
W rzadkich przypadkach widziałem, jak SQL Server 2008R2 optymalizuje skorelowane podzapytania do łączenia przez scalanie (które przechodzi przez oba zestawy tylko raz - najlepszy możliwy scenariusz), gdzie odpowiedni indeks można znaleźć zarówno w zapytaniach wewnętrznych, jak i zewnętrznych.
Prawdziwym winowajcą złej wydajności niekoniecznie są skorelowane podzapytania , ale zagnieżdżone skany .
