To zależy.. Ogólnie rzecz biorąc, Oracle nie gwarantuje, że instrukcja SQL użyje oceny zwarcia (chociaż PL/SQL gwarantuje wykonanie oceny zwarcia). Optymalizator Oracle może dowolnie oceniać predykaty w dowolnej kolejności, w której oczekuje, że będzie najbardziej wydajny. Może to oznaczać, że pierwszy predykat jest oceniany jako pierwszy i tylko pasujące wiersze mają oceniany drugi predykat, ale jest całkowicie możliwe, że stanie się odwrotnie lub że Oracle przekształci zapytanie w coś w rodzaju UNION i w pełni ocenia oba predykaty przed połączeniem wyników.
Biorąc to pod uwagę, jeśli optymalizator może określić w czasie kompilacji, że predykat zawsze będzie oceniał jako TRUE lub FALSE , optymalizator powinien po prostu traktować to jako stałą. Więc jeśli na przykład istnieje ograniczenie w tabeli, które uniemożliwia X od zawsze wartości „prawda”, optymalizator nie powinien w ogóle oceniać drugiego predykatu (chociaż różne wersje optymalizatora będą miały różne możliwości wykrywania, że coś jest stałe w czasie kompilacji).
Jeśli chodzi o drugą część pytania, nie widząc planów zapytań, bardzo trudno to powiedzieć. Optymalizator Oracle wydaje się być całkiem dobry w przekształcaniu zapytań z jednej formy w drugą, jeśli istnieją bardziej wydajne sposoby ich oceny. Ogólnie jednak, jeśli subQ zwróci stosunkowo dużą liczbę wierszy w porównaniu do table , bardziej wydajne może być skonstruowanie zapytania jako EXISTS zamiast jako IN .
