with recursive必须置于语句最前端，不可嵌套；需含非递归项与递归项，用union all连接；列数类型须一致；应设深度限制防无限循环。
WITH RECURSIVE 语法必须写在最前面，不能嵌套在子查询里
很多人写完 SELECT 才想起来要递归，硬把 WITH RECURSIVE 塞进 FROM 子句里，结果直接报错：ERROR: syntax error at or near "WITH"。它不是普通 CTE，是独立的顶层结构，必须紧贴语句开头，后面紧跟主查询。
实操建议：
-
WITH RECURSIVE后面直接跟递归 CTE 的定义（cte_name AS ( ... )），再换行写SELECT - 不能出现在视图定义、函数体或
INSERT ... SELECT的子查询中——除非整个语句以WITH RECURSIVE开头 - PostgreSQL 支持，MySQL 8.0+ 支持，SQLite 3.8.3+ 支持；但 SQL Server 用
WITH+UNION ALL（不加RECURSIVE关键字）
递归 CTE 必须包含非递归项和递归项，且 UNION ALL 是强制连接方式
只写一次 SELECT 或用 UNION（而非 UNION ALL）都会失败。数据库需要明确区分“起点”和“迭代逻辑”，否则无法初始化或陷入死循环。
常见错误现象：
- 漏掉初始查询（anchor member），比如只写
SELECT * FROM tree WHERE parent_id = 1的递归部分，没写根节点查询 - 递归查询里意外引入了未在非递归项中出现的列（如多选了一个计算字段），导致列数/类型不匹配
- 用了
UNION：数据库会去重，但递归过程依赖逐层追加，去重可能删掉关键中间结果，甚至让迭代提前终止
示例（组织架构查下属）：
WITH RECURSIVE subordinates AS ( SELECT id, name, manager_id, 1 AS level FROM employees WHERE id = 123 -- 非递归项：从指定员工开始 UNION ALL SELECT e.id, e.name, e.manager_id, s.level + 1 FROM employees e INNER JOIN subordinates s ON e.manager_id = s.id -- 递归项：找所有直接下属 ) SELECT * FROM subordinates;
不设终止条件会无限循环，max_recursion_depth 不是万能保险
递归没有自然退出机制。如果数据存在环（比如 A 管 B、B 管 C、C 又管 A），或者 JOIN 条件始终成立，查询会一直跑直到超时或达到数据库限制。
实操建议：
- 显式加深度限制：在递归项中增加
s.level 这类判断（<code>level字段需在非递归和递归项中都定义） - 避免用
WHERE NOT IN (SELECT ...)做防环——子查询在递归中不可用，会报ERROR: recursive reference in a subquery - PostgreSQL 可设
statement_timeout或调整work_mem，但别依赖max_recursive_iterations（MySQL 的配置项，且仅当未手动限制时才生效）
JOIN 方向写反会导致查不到任何递归结果
递归项里 INNER JOIN subordinates s ON e.manager_id = s.id 和 INNER JOIN subordinates s ON s.manager_id = e.id 看似对称，实际语义完全相反：前者是“找 s 的下属”，后者是“找 s 的上级”，方向错了整棵树就挂了。
使用场景提示：
- 查子孙（向下递归）：递归项中让子表字段（如
e.parent_id）等于 CTE 中的主键（s.id） - 查祖先（向上递归）：让子表字段（如
e.id）等于 CTE 中的外键（s.parent_id） - MySQL 中若用
LEFT JOIN，空匹配会让整行变 NULL，进而使UNION ALL停止扩展——务必用INNER JOIN保证路径连通
递归查询真正难的不是语法，是想清楚“谁指向谁”“从哪出发”“在哪收手”。数据里藏了个环，或者层级字段为空，WITH RECURSIVE 就会安静地返回空结果集，连警告都没有。
