Detta är ett RDBMS-agnostiskt svar, men kan ändå hjälpa. Enligt min uppfattning är den korrelerade (aka, beroende) underfrågan den kanske oftast felaktigt anklagade boven för dålig prestanda.
Problemet (som det oftast beskrivs) är att det bearbetar den inre frågan för varje rad i den yttre frågan. Därför, om den yttre frågan returnerar 1 000 rader, och den inre frågan returnerar 10 000, måste din fråga gå igenom 10 000 000 rader (yttre×inre) för att ge ett resultat. Jämfört med de 11 000 raderna (yttre+inre) från en icke-korrelerad fråga över samma resultatuppsättningar, är det inte bra.
Detta är dock bara det värsta scenariot. I många fall kommer DBMS att kunna utnyttja index för att drastiskt minska antalet rader. Även om bara den inre frågan kan använda ett index, blir de 10 000 raderna ~13 sökningar, vilket sänker summan till 13 000.
exists operatören kan sluta bearbeta rader efter den första, vilket minskar frågekostnaden ytterligare, särskilt när de flesta yttre raderna matchar minst en inre rad.
I några sällsynta fall har jag sett SQL Server 2008R2 optimera korrelerade delfrågor till en sammanfogning (som går igenom båda uppsättningarna endast en gång - bästa möjliga scenario) där ett lämpligt index kan hittas i både inre och yttre frågor.
Den verkliga boven för dålig prestanda är inte nödvändigtvis korrelerade underfrågor , men kapslade skanningar .