SQL Server递归查询必须加OPTION (MAXRECURSION n)，否则超100层即报错Msg 530中断执行；默认100是硬限制，解决方法为设合理上限（如500）或用0（需确保终止条件），且该选项须置于SELECT末尾、不可写在CTE内。
SQL Server 必须加 OPTION (MAXRECURSION n) 才能跑通
不加这个选项，递归超过100层就直接报错 Msg 530, Level 16, State 1，不是警告，是查询中断。默认100是硬限制，不是性能建议。
实际组织架构常超100级（比如多级代理、BOM嵌套配件），解决办法只有两个：
-
OPTION (MAXRECURSION 0)：不限制递归深度，但必须确保锚点和JOIN条件能自然终止，否则会死循环 -
OPTION (MAXRECURSION 500)：设一个合理上限，既防失控又够用，推荐在生产环境用这个
注意：OPTION (MAXRECURSION ...) 必须放在整个 SELECT 语句末尾，不能写在 CTE 定义里，也不能跨语句复用。
WITH RECURSIVE 在 MySQL/PostgreSQL 和 SQL Server 写法不同
MySQL 8.0+ 和 PostgreSQL 必须显式写 WITH RECURSIVE；SQL Server 只要 WITH 就行，加 RECURSIVE 反而报错。
锚点（初始查询）和递归部分的顺序也关键：
- SQL Server 要求锚点必须在
UNION ALL左侧，递归查询在右侧；写反了报Msg 319 - MySQL/PostgreSQL 同样要求逻辑顺序正确，但错误提示不如 SQL Server 明确，容易卡在空结果或无限循环
典型结构示例（查“技术部”及其所有下级）：
WITH dept_tree AS ( SELECT id, name, parent_id, 0 AS level FROM organization WHERE id = 2 -- 锚点：技术部本身 UNION ALL SELECT o.id, o.name, o.parent_id, dt.level + 1 FROM organization o INNER JOIN dept_tree dt ON o.parent_id = dt.id -- 注意方向：子表.parent_id = CTE.id ) SELECT * FROM dept_tree OPTION (MAXRECURSION 500);
查完整路径（根→当前）得手动拼接 path 字段
CTE 本身不保存路径，只存层级关系。要生成类似 总公司 → 技术部 → 开发组 这种面包屑，必须在递归中累积字符串或数组。
常见做法是用 CAST + CONCAT 构建可排序的路径字段：
- 锚点里初始化：
CAST(name AS VARCHAR(500)) AS path - 递归部分追加：
CONCAT(t.path, ' → ', e.name) - 注意长度限制，
VARCHAR(500)不够时得调大，否则截断
如果路径含特殊字符（如单引号、括号），纯字符串拼接易出错，此时应优先考虑应用层组装，或改用 JSON 数组（PostgreSQL 支持 jsonb_agg 向上累积）。
性能关键：parent_id 字段必须有索引
递归每轮都靠 JOIN ... ON child.parent_id = parent.id 找下级，没索引会导致全表扫描，层数一深性能断崖下跌。
实测万级节点下，有索引时递归查询通常
其他优化点：
- 避免在递归部分用
LEFT JOIN—— 会引入 NULL 匹配，导致重复或发散 - 锚点漏掉
level或path字段，后续无法按深度过滤、排序或限界 - 不要在递归 CTE 中
SELECT *，只选真正需要的列，减少内存和网络开销
最易被忽略的是：递归终止完全依赖数据质量。如果存在环形引用（A → B → C → A），哪怕加了 MAXRECURSION，也会在达到上限时报错而非静默失败。上线前务必校验 parent_id 的合法性。
