cte递归必须紧贴dml语句开头，with须为首词；变量需在cte前声明并作用域覆盖整条语句；须设锚点筛选、递归推进、防环判断及option(maxrecursion)；排序依赖路径字段而非order by。
CTE递归必须紧贴DML语句开头，不能嵌套在IF或DECLARE之后
存储过程里写递归CTE，最常卡在语法位置上——WITH必须是整个语句的第一个词，前面不能有DECLARE、SET、注释甚至空行。SQL Server某些版本会直接报错Incorrect syntax near 'WITH'。
- 错误写法：
DECLARE @tenant_id INT = 123; WITH org_cte AS (...)→ 报错 - 正确写法：把
WITH直接放在SELECT、INSERT或UPDATE前，例如SELECT * FROM (WITH org_cte AS (...) SELECT ...) t，或更稳妥地单独成句：WITH org_cte AS (...) SELECT ... - IF分支内要用递归CTE？必须整个分支是一条完整查询语句，不能只定义CTE不执行；否则CTE生命周期结束，后续语句无法引用
递归CTE里不能用@变量？其实能，但必须确保作用域可见
CTE本身不感知存储过程变量，但它所在的那条DML语句可以。关键在于：变量必须在CTE定义**之前已声明且作用域覆盖整条语句**。
- 锚点部分可用
WHERE manager_id = @tenant_id，但前提是@tenant_id已在存储过程开头DECLARE并赋值 - 递归部分JOIN条件里也能用
@tenant_id，比如ON e.tenant_id = @tenant_id AND e.parent_id = cte.id - 常见错误：
Must declare the scalar variable "@tenant_id"，往往是因为变量声明在CTE语句之后，或被包裹在未执行的IF块里 - 安全做法：所有参数变量统一在存储过程头部
DECLARE，并在递归CTE语句前用SET或SELECT赋值
递归深度超限、无限循环？必须加OPTION(MAXRECURSION)和防环字段
SQL Server默认只允许100层递归，而组织架构或BOM表常超此限；更危险的是数据脏导致的无限循环——比如父子ID相同、空parent_id没过滤。
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 必须在最终
SELECT或INSERT语句末尾显式加OPTION (MAXRECURSION 32767)（别用0） - 锚点必须严格筛选顶层节点，如
WHERE parent_id IS NULL AND tenant_id = @tenant_id - 递归部分JOIN条件务必推进层级：
ON e.parent_id = cte.id，而不是反向写成ON e.id = cte.parent_id - 加兜底防环：
AND e.id != cte.id，再配合level 这类硬限制 - 调试时在CTE里输出
level和path字段，一眼看出是否卡在某一层
递归结果要按树形顺序排？ORDER BY放外层，路径字段才是关键
CTE内部ORDER BY无效，外层ORDER BY又可能被并行执行打乱层级顺序。真要“根→子→孙”排列，得靠生成可排序的路径字段。
- 锚点设
sort_path = CAST(id AS VARCHAR(50))，递归部分拼接sort_path = cte.sort_path + '/' + CAST(e.id AS VARCHAR(10)) - 最终查询用
ORDER BY sort_path，就能保证深度优先顺序 - 若只需按层级分组展示，加
level INT列（锚点=1，递归部分=cte.level + 1），再ORDER BY level, id - 别在CTE里写
ORDER BY，SQL Server会直接报错The ORDER BY clause is invalid in common table expressions
CTE递归真正难的不是语法，而是数据质量校验和终止条件设计——路径字段、层级计数、防环判断，这些都得在CTE定义里就写实，不能指望外层补救。
