Dit is een RDBMS-agnostisch antwoord, maar kan toch helpen. Naar mijn mening is de gecorreleerde (ook wel afhankelijke) subquery misschien wel de meest valselijk beschuldigde boosdoener voor slechte prestaties.
Het probleem (zoals het vaakst wordt beschreven) is dat het de inner query voor elke rij van de outer query verwerkt. Daarom, als de buitenste query 1.000 rijen retourneert en de binnenste query 10.000, dan moet uw query door 10.000.000 rijen (buitenste × binnenste) ploeteren om een resultaat te produceren. Vergeleken met de 11.000 rijen (buiten+binnen) van een niet-gecorreleerde zoekopdracht over dezelfde resultatensets, is dat niet goed.
Dit is echter slechts het worstcasescenario. In veel gevallen zal het DBMS indexen kunnen misbruiken om het aantal rijen drastisch te verminderen. Zelfs als alleen de innerlijke query een index kan gebruiken, worden de 10.000 rijen ~13 zoekopdrachten, waardoor het totaal daalt tot 13.000.
De exists operator kan de verwerking van rijen na de eerste stopzetten, waardoor de querykosten verder worden verlaagd, vooral wanneer de meeste buitenste rijen overeenkomen met ten minste één binnenste rij.
In enkele zeldzame gevallen heb ik SQL Server 2008R2 gecorreleerde subquery's zien optimaliseren tot een merge-join (die beide sets slechts één keer doorloopt - het best mogelijke scenario) waarbij een geschikte index kan worden gevonden in zowel inner- als outer-query's.
De echte boosdoener voor slechte prestaties zijn niet noodzakelijk gecorreleerde subquery's , maar geneste scans .