Toto je odpověď agnostická RDBMS, ale přesto může pomoci. Podle mého chápání je korelovaný (neboli závislý) poddotaz možná nejčastěji falešně obviněným viníkem špatného výkonu.
Problém (jak je nejčastěji popisován) je v tom, že zpracovává vnitřní dotaz pro každý řádek vnějšího dotazu. Pokud tedy vnější dotaz vrátí 1 000 řádků a vnitřní dotaz vrátí 10 000, musí váš dotaz projít 10 000 000 řádky (vnější × vnitřní), aby vytvořil výsledek. Ve srovnání s 11 000 řádky (vnější + vnitřní) z nekorelovaného dotazu na stejné sady výsledků to není dobré.
To je však jen ten nejhorší možný scénář. V mnoha případech bude systém DBMS schopen využívat indexy k výraznému snížení počtu řádků. I když index může používat pouze vnitřní dotaz, z 10 000 řádků se stane ~13 hledání, což sníží celkový počet na 13 000.
exists Operátor může zastavit zpracování řádků po prvním, čímž dále sníží náklady na dotaz, zvláště když většina vnějších řádků odpovídá alespoň jednomu vnitřnímu řádku.
V některých vzácných případech jsem viděl, jak SQL Server 2008R2 optimalizuje korelované poddotazy na slučovací spojení (které prochází oběma sadami pouze jednou – nejlepší možný scénář), kde lze nalézt vhodný index ve vnitřních i vnějších dotazech.
Skutečným viníkem špatného výkonu nemusí být nutně korelované poddotazy , ale vnořené kontroly .