Odpowiedź jest prosta.
SQL Server nie realizuje CTE. Zawiera je, jak widać z planów wykonania.
Inne DBMS mogą zaimplementować to inaczej, dobrze znanym przykładem jest Postgres, który materializuje CTE (zasadniczo tworzy tymczasowe tabele CTE za maską).
To, czy jawna materializacja wyników pośrednika w jawnych tabelach tymczasowych jest szybsza, zależy od zapytania.
W złożonych zapytaniach narzut związany z zapisem i odczytem danych pośrednich do tabel tymczasowych może zostać zrekompensowany przez wydajniejsze, prostsze plany wykonania, które optymalizator jest w stanie wygenerować.
Z drugiej strony w Postgres CTE jest „ogrodzeniem optymalizacji”, a silnik nie może przepychać predykatów poza granicę CTE.
Czasem jeden sposób jest lepszy, czasem inny. Gdy złożoność zapytania przekroczy pewien próg, optymalizator nie może przeanalizować wszystkich możliwych sposobów przetwarzania danych i musi się na czymś poprzestać. Na przykład kolejność łączenia stołów. Liczba permutacji rośnie wykładniczo wraz z liczbą tabel do wyboru. Optymalizator ma ograniczony czas na wygenerowanie planu, więc może być złym wyborem, gdy wszystkie CTE są uwzględnione. Kiedy ręcznie dzielisz złożone zapytania na mniejsze, prostsze, musisz zrozumieć, co robisz, ale optymalizator ma większą szansę na wygenerowanie dobrego planu dla każdego prostego zapytania.
