Odpověď je jednoduchá.
SQL Server nerealizuje CTE. Vkládá je, jak můžete vidět z prováděcích plánů.
Jiné DBMS to mohou implementovat jinak, známým příkladem je Postgres, který zhmotňuje CTE (v podstatě vytváří dočasné tabulky pro CTE za kapotou).
Zda je explicitní materializace zprostředkovaných výsledků v explicitních dočasných tabulkách rychlejší, závisí na dotazu.
U složitých dotazů lze režii zápisu a čtení zprostředkovatelských dat do dočasných tabulek kompenzovat efektivnějšími jednoduššími prováděcími plány, které je optimalizátor schopen generovat.
Na druhou stranu v Postgresu je CTE „optimalizační plot“ a engine nemůže posouvat predikáty přes hranici CTE.
Někdy je lepší jeden způsob, někdy jiný. Jakmile složitost dotazu překročí určitou hranici, optimalizátor nemůže analyzovat všechny možné způsoby zpracování dat a musí se s něčím usadit. Například pořadí, ve kterém se ke stolům připojují. Počet permutací roste exponenciálně s počtem tabulek, ze kterých si můžete vybrat. Optimalizátor má omezený čas na vygenerování plánu, takže může udělat špatnou volbu, když jsou všechny CTE inline. Když ručně rozdělíte složitý dotaz na menší, jednodušší, musíte pochopit, co děláte, ale optimalizátor má větší šanci vygenerovat dobrý plán pro každý jednoduchý dotaz.