sql server不支持嵌套cte，只允许单个with子句定义多个逗号分隔的线性依赖cte；其性能瓶颈在于默认内联展开导致重复计算，而非语法嵌套，优化关键为控制物化时机、切断重复扫描、对齐索引。
SQL Server 不支持嵌套 CTE，所谓“嵌套CTE后的分组聚合”实际是多个顺序 CTE 的链式依赖；优化关键不在语法嵌套，而在控制物化时机、切断重复扫描、对齐索引。
为什么你写的“嵌套CTE”根本没嵌套
SQL Server（2019/2022/2025）只允许单个 WITH 子句，其后跟逗号分隔的多个 CTE 定义。你在第二个 CTE 里写 WITH，会直接报错 Incorrect syntax near 'WITH'。所谓“嵌套”，其实是误读——真实结构是：cte1 AS (...), cte2 AS (SELECT ... FROM cte1), cte3 AS (SELECT ... FROM cte2)。它们线性引用，但默认不物化，cte2 每次被引用都可能重算 cte1。
- 查执行计划：如果
cte1出现在多个地方（比如被cte2和cte3同时引用），且执行计划里出现多次相同扫描或聚合节点，说明它被重复执行了 - 别信“CTE 自动缓存”——SQL Server 默认内联展开，不是临时表
- 递归 CTE 是特例，但它内部的锚点+递归成员不算“嵌套 CTE”，而是单个 CTE 的固定语法结构
分组聚合慢？先看中间结果有没有被反复 GROUP BY
典型症状：外层 GROUP BY 耗时飙升，EXPLAIN 显示 Warning: Null value is eliminated by an aggregate or other SET operation 或大量 Compute Scalar 节点。根源常是：你在 CTE 里漏掉了必要聚合字段，导致主查询被迫对宽表再做一次 GROUP BY，而这张宽表已含百万行。
- 在最早一个聚合 CTE 里，必须
GROUP BY所有后续步骤需要的维度列（如user_id, region），并显式计算所有聚合值（COUNT(*),SUM(amount)），别留到最外层再算 - 禁止在 CTE 中用
SELECT *：字段顺序和数量一旦基表变更，cte2引用时可能列错位，引发分组逻辑错误 - 如果主查询只按
region分组，但cte1是按user_id聚合的，那cte2必须先按region再聚合一次——这步不能省，否则数据粒度不匹配
怎么让 SQL Server 真正“记住”中间结果
想避免重复计算，就得绕过默认内联行为。SQL Server 没有 MATERIALIZED 关键字，但有三个实操路径：
- 用
OPTION (RECOMPILE)：强制优化器在运行时重新评估 CTE 是否值得物化（尤其当参数值显著影响结果集大小时） - 改用临时表：把关键聚合结果写入
#tmp_agg，并在其上建索引（如CREATE INDEX IX_tmp_region ON #tmp_agg(region)），比任何 CTE 都可靠 - 拆成两步语句：第一步
INSERT INTO #tmp SELECT ... GROUP BY ...，第二步SELECT ... FROM #tmp GROUP BY ...——虽然代码长点，但执行计划完全可控 - 慎用
VIEW替代 CTE：视图不解决物化问题，反而可能隐藏性能陷阱
GROUP BY 字段顺序不匹配索引？CTE 再好也白搭
即使你把所有聚合提前到 CTE 里，如果最终 GROUP BY region, dept，而索引是 (dept, region)，SQL Server 仍会触发 Hash Match Aggregate 或排序，无法走索引跳扫。
- 检查
cte3的最终GROUP BY列顺序，必须和目标索引前导列严格一致 - 若需
GROUP BY region DESC, dept ASC，SQL Server 2022+ 支持混合方向索引，但得显式创建：CREATE INDEX IX_region_dept ON #tmp_agg(region DESC, dept ASC) - 别依赖“SQL Server 自动优化索引使用”——它不会为 CTE 中间结果自动建索引，索引必须建在物理表或临时表上
真正卡住性能的，往往不是 CTE 写法本身，而是中间结果集是否被设计成可索引、可复用、不可变的结构。每多一层 CTE，就多一次优化器误判的风险；不如早一步落地到临时表，把不确定性收口。
