Dette er et RDBMS-agnostisk svar, men kan ikke desto mindre hjælpe. Efter min forståelse er den korrelerede (alias, afhængige) underforespørgsel måske den oftest falsk anklagede skyldige for dårlig ydeevne.
Problemet (som det oftest beskrives) er, at det behandler den indre forespørgsel for hver række af den ydre forespørgsel. Derfor, hvis den ydre forespørgsel returnerer 1.000 rækker, og den indre forespørgsel returnerer 10.000, så skal din forespørgsel gennemløbe 10.000.000 rækker (ydre × indre) for at producere et resultat. Sammenlignet med de 11.000 rækker (ydre+indre) fra en ikke-korreleret forespørgsel over de samme resultatsæt, er det ikke godt.
Dette er dog kun det værste tilfælde. I mange tilfælde vil DBMS være i stand til at udnytte indekser til drastisk at reducere rækkeantallet. Selvom kun den indre forespørgsel kan bruge et indeks, bliver de 10.000 rækker til ~13 søgninger, hvilket sænker det samlede antal til 13.000.
exists operatør kan stoppe med at behandle rækker efter den første, hvilket reducerer forespørgselsomkostningerne yderligere, især når de fleste ydre rækker matcher mindst én indre række.
I nogle sjældne tilfælde har jeg set SQL Server 2008R2 optimere korrelerede underforespørgsler til en merge join (som kun krydser begge sæt én gang - bedst mulige scenarie), hvor et passende indeks kan findes i både indre og ydre forespørgsler.
Den virkelige synder for dårlig ydeevne er ikke nødvendigvis korrelerede underforespørgsler , men indlejrede scanninger .