Svaret er enkelt.
SQL Server realiserer ikke CTE'er. Det inlines dem, som du kan se af udførelsesplanerne.
Andre DBMS kan implementere det anderledes, et velkendt eksempel er Postgres, som virkelig materialiserer CTE'er (det opretter i det væsentlige midlertidige tabeller for CTE'er bag emhætten).
Hvorvidt eksplicit materialisering af mellemliggende resultater i eksplicitte midlertidige tabeller er hurtigere, afhænger af forespørgslen.
I komplekse forespørgsler kan overheaden med at skrive og læse mellemliggende data i midlertidige tabeller opvejes af mere effektive og enklere eksekveringsplaner, som optimizer er i stand til at generere.
På den anden side er CTE i Postgres et "optimeringshegn", og motoren kan ikke skubbe prædikater på tværs af CTE-grænsen.
Nogle gange er én måde bedre, nogle gange en anden. Når forespørgslens kompleksitet vokser ud over en bestemt tærskel, kan en optimeringsmaskine ikke analysere alle mulige måder at behandle data på, og den må tage stilling til noget. F.eks. rækkefølgen, hvori man skal slutte sig til bordene. Antallet af permutationer vokser eksponentielt med antallet af tabeller at vælge imellem. Optimizer har begrænset tid til at generere en plan, så det kan være et dårligt valg, når alle CTE'er er inlinet. Når du manuelt deler komplekse forespørgsler op i mindre simple forespørgsler, skal du forstå, hvad du laver, men optimeringsværktøjet har en bedre chance for at generere en god plan for hver enkelt forespørgsel.