Това е RDBMS-агностичен отговор, но въпреки това може да помогне. Според мен корелираната (известна още като зависима) подзаявка е може би най-често фалшиво обвиняемият виновник за лошо представяне.
Проблемът (както най-често се описва) е, че обработва вътрешната заявка за всеки ред от външната заявка. Следователно, ако външната заявка върне 1 000 реда, а вътрешната 10 000, тогава вашата заявка трябва да премине през 10 000 000 реда (външни × вътрешни), за да даде резултат. В сравнение с 11 000 реда (външни+вътрешни) от некорелирана заявка върху същите набори от резултати, това не е добре.
Това обаче е само най-лошият сценарий. В много случаи СУБД ще може да използва индекси, за да намали драстично броя на редовете. Дори ако само вътрешната заявка може да използва индекс, 10 000 реда стават ~13 търсения, което намалява общия брой до 13 000.
exists Операторът може да спре обработката на редове след първия, намалявайки допълнително разходите за заявка, особено когато повечето външни редове съвпадат с поне един вътрешен ред.
В някои редки случаи съм виждал SQL Server 2008R2 да оптимизира корелирани подзаявки към обединяване за сливане (което преминава и двата набора само веднъж – най-добрият възможен сценарий), където подходящ индекс може да бъде намерен както във вътрешни, така и във външни заявки.
Истинският виновник за лошото представяне не е непременно корелирани подзаявки , но вложени сканирания .
