sql server中cte递归需在末尾加option (maxrecursion n)避免超100层报错；n为预估最大层级，0表示不限但须有明确终止条件；锚点与递归成员必须用union all；终止条件须写在递归成员where子句中。
CTE递归怎么写才不报错MAXRECURSION
SQL Server默认递归深度是100层，一旦树形结构更深（比如组织架构超过100级、BOM物料展开过深），直接报错Query processor could not produce a query plan because the statement exceeded the maximum recursion limit。这不是语法错，是安全限制。
实操建议：
- 必须在语句末尾加
OPTION (MAXRECURSION n)，n填预估最大层级（如OPTION (MAXRECURSION 500)）；设为0表示不限制——但要确保有明确的终止条件，否则真会死循环 - 递归锚点（anchor）和递归成员（recursive member）之间必须用
UNION ALL，不能用UNION（去重开销大且可能中断递归逻辑） - 终止条件必须写在递归成员的
WHERE里，比如WHERE parent_id = t.id要配合t.level 这类显式层数控制，光靠数据关系不够稳
MySQL 8.0+ 怎么模拟WITH RECURSIVE效果
MySQL直到8.0才支持标准CTE递归，老版本只能靠自连接或存储过程硬扛，但层级一多就慢得没法看。即使在8.0+，也容易踩几个坑。
实操建议：
- 递归查询必须包含
WITH RECURSIVE前缀，漏掉RECURSIVE关键字会直接报错ERROR 1248: Every derived table must have its own alias - 锚点查询不能是空结果集，否则整个CTE返回空——哪怕你确定有数据，也要检查
WHERE条件是否误过滤了根节点（比如parent_id IS NULL写成parent_id = 0） - 避免在递归成员中使用非确定性函数（如
NOW()、RAND()），MySQL会拒绝执行
JOIN太多导致性能崩了，是不是该全换成CTE递归
不是。CTE递归解决的是“动态层级遍历”问题，不是“多表关联性能优化”的万能药。把原本三张表的LEFT JOIN硬改成递归CTE，反而更慢。
实操建议：
- 先确认瓶颈：用
EXPLAIN或执行计划看是不是真的卡在JOIN顺序/索引缺失上，而不是层级逻辑本身 - 如果只是4–5层固定JOIN（比如订单→用户→部门→区域→省份），用普通JOIN + 合适索引比CTE快得多
- 只有当层级深度不确定、路径需动态展开（如查某个节点的所有子孙、所有祖先路径）时，CTE递归才有不可替代性
- PostgreSQL里可以给递归CTE加
LIMIT提前截断，但SQL Server和MySQL不支持，得靠level字段手动控制
parent_id为NULL的根节点总被漏掉
这是最常被忽略的细节：递归CTE的锚点部分只跑一次，如果它没捞出根节点，后续所有递归都基于空集，结果自然为空。
实操建议：
- 锚点查询必须显式覆盖根节点，常见写法是
WHERE parent_id IS NULL或WHERE id = @root_id，别指望递归部分能补回来 - 注意NULL处理差异：SQL Server对
NULL = NULL判FALSE，MySQL默认也是；但某些场景下parent_id存的是字符串'null'或数字0，得统一清洗 - 加个
level字段从1开始计数，输出时一眼就能看出哪层是根：SELECT id, name, 1 AS level FROM tree WHERE parent_id IS NULL
