SQL Server 中WITH定义的是顺序引用的CTE而非嵌套CTE，因语法仅允许最外层单次WITH，内部再写WITH会报错“Incorrect syntax near 'WITH'”；正确做法是按依赖关系依次定义多个CTE。
SQL Server 中用 WITH 定义多层嵌套查询，本质不是“嵌套 CTE”，而是多个**顺序引用的 CTE**——真正嵌套（即一个 CTE 定义里再写 WITH）在标准 SQL Server（非 Fabric 数据仓库）中不被支持，强行写会报错 Incorrect syntax near the keyword 'WITH'。
为什么不能真嵌套：SQL Server 不支持嵌套 CTE 语法
很多人看到“嵌套 CTE”这个词，下意识以为可以在一个 CTE 的定义体里再写 WITH。但 SQL Server（2019/2022 等主流版本）只允许在语句最外层使用一次 WITH，其后跟若干逗号分隔的 CTE 定义，它们是平级并列、依次依赖的关系，不是语法树上的嵌套结构。
常见错误现象：
- 在
AS ( ... )括号内又写WITH xxx AS (...)→ 报错Incorrect syntax near 'WITH' - 试图在
UPDATE或INSERT语句中用多个 CTE，但漏掉最外层WITH→ 报错Incorrect syntax near 'UPDATE'
Fabric 数据仓库虽支持嵌套 CTE，但仅限其特定环境，且不支持 UPDATE/INSERT/DELETE 中使用——这和通用 SQL Server 场景无关，别混淆。
正确做法：用顺序 CTE 拆解多层逻辑
所谓“多层嵌套查询”的需求，实际是把复杂计算分步：先算中间聚合，再基于结果过滤，再关联其他表，最后加工输出。这时应定义多个 CTE，按依赖顺序排列，后一个 CTE 可引用前一个。
实操建议：
- 第一个 CTE 做原始数据清洗或轻量聚合，比如
WITH base AS (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM ...) - 第二个 CTE 引用
base，做筛选或扩展字段，如filtered AS (SELECT * FROM base WHERE rn - 第三个 CTE 关联维度表，如
enriched AS (SELECT f.*, d.name FROM filtered f JOIN dim d ON f.id = d.id) - 最终
SELECT只需从最后一个 CTE 查询，避免重复写大子查询
注意：CTE 名称在同一个 WITH 子句中必须唯一；列别名若未显式声明，将沿用子查询中的列名，但一旦有歧义（如两个表同名列），必须用 (col1, col2) 显式指定。
递归 CTE 是另一类，别和“多层”混淆
递归 CTE（如查部门树、BOM 展开）确实涉及“多层”，但它靠 UNION ALL 连接锚点查询和递归成员，结构固定：WITH tree AS (anchor UNION ALL recursive)。这不是“多层嵌套 CTE”，而是单个 CTE 内部的递归定义。
容易踩的坑：
- 忘了加
MAXRECURSION限制，导致无限循环或报错The statement terminated. The maximum recursion 100 has been exhausted - 递归部分没正确关联上一层结果（比如漏写
ON t.parent_id = r.id），导致变成笛卡尔积 - 没建好索引：递归每层都可能触发父表扫描，
parent_id字段必须有索引，否则性能断崖下跌
示例关键片段：WITH org_tree AS (SELECT id, name, parent_id, 0 AS level FROM dept WHERE parent_id IS NULL UNION ALL SELECT d.id, d.name, d.parent_id, ot.level + 1 FROM dept d INNER JOIN org_tree ot ON d.parent_id = ot.id) SELECT * FROM org_tree OPTION (MAXRECURSION 32);
CTE 不是万能缓存，多次引用仍会重执行
有人以为定义一次 CTE 就像临时表一样物化了结果，其实不然。每次在外部查询中引用同一个 CTE，SQL Server 都会重新执行其定义的 SELECT。如果某个 CTE 被引用三次，它就执行三次。
这意味着：
- 对大数据量或高成本子查询（如含聚合、排序、远程查询），反复引用 CTE 可能比用
#temp表更慢 - 若需多次复用中间结果，且数据量超 1 万行，优先考虑
SELECT ... INTO #tmp+ 索引 - CTE 的优势在于逻辑清晰、避免重复写相同子查询文本，不是性能优化手段
简单判断：如果 CTE 定义里只有 WHERE 和 JOIN，无聚合/排序/函数，那重执行开销小，放心用；一旦出现 GROUP BY 或 ORDER BY，就得掂量是否该换临时表。
