递归CTE必须位于查询顶层，不可嵌套于子查询中；应通过CTE链式定义或与子查询分层协作（子查询预处理、递归CTE专注遍历）来实现复用。
递归CTE不能直接嵌套在子查询里，但可以和子查询在同一查询中分层协作——关键在于让子查询处理静态聚合或过滤，递归CTE专注层级遍历，两者通过 JOIN 或 WHERE 关联。
为什么不能把递归CTE写进子查询括号里
递归CTE（WITH RECURSIVE）必须是整个查询的顶层结构，SQL标准不允许它出现在子查询的 FROM 或 WHERE 中。比如下面这种写法会报错：
SELECT * FROM ( WITH RECURSIVE tree AS (...) SELECT * FROM tree ) t;
错误信息通常是：Recursive common table expression must be at top level（不同数据库提示略有差异，但本质一致）。
- MySQL 8.0+、PostgreSQL、SQL Server 都强制要求递归CTE必须紧接在
SELECT/INSERT等主语句之前，且不能被括号包裹 - 子查询是独立执行单元，而递归CTE依赖自身引用和迭代机制，生命周期和执行模型不兼容
- 想“复用”递归结果？得靠 CTE 链式定义，而不是子查询套娃
正确协作方式：先用子查询预处理，再用递归CTE展开
典型场景：查某个部门下所有员工，但只统计“2025年入职且职级≥P6”的上级链路。这时子查询负责筛选锚点，递归CTE负责向上追溯。
- 子查询输出的是**单层、确定性结果集**，比如一个或多个
employee_id列表 - 递归CTE 的 anchor member（初始查询）直接
SELECT ... FROM (子查询)，避免硬编码 ID - 后续递归 member 只跟自身或上一层关联，不碰原始子查询逻辑
示例（MySQL）：
WITH RECURSIVE org_path AS (
-- anchor：从子查询结果开始
SELECT id, name, manager_id, 1 AS level
FROM employees
WHERE id IN (
SELECT id FROM employees
WHERE hire_date >= '2025-01-01' AND level_code >= 'P6'
)
UNION ALL
-- recursive：只查 manager_id 对应的上级
SELECT e.id, e.name, e.manager_id, op.level + 1
FROM employees e
INNER JOIN org_path op ON e.id = op.manager_id
)
SELECT * FROM org_path;容易踩的坑：JOIN 位置与层级爆炸
如果在递归CTE外部再套一层子查询做 JOIN，很容易触发重复计算或无限递归——尤其当子查询结果含多行且未限制层级时。
- 递归CTE默认无深度限制，MySQL 用
cte_max_recursion_depth系统变量控制，默认 1000；超限报错：Recursive query aborted after 1000 iterations - 子查询若返回 10 个员工，anchor 就启动 10 条独立递归路径，性能陡增；加
LIMIT在子查询里比在最终SELECT里更有效 - 别在递归 member 的
JOIN条件里引用子查询——它已不可见；所有过滤必须前置到 anchor 或递归后加WHERE
替代方案：用非递归CTE链代替“子查询+递归CTE”混合
真正需要多次复用中间结果时，优先走 CTE 链式定义，而非强行塞子查询：
- 第一段 CTE 做筛选：
qualified_employees AS (SELECT id FROM employees WHERE ...) - 第二段 CTE 是递归：
RECURSIVE chain AS (SELECT * FROM qualified_employees UNION ALL ...) - 最后
SELECT引用chain，必要时再JOIN其他表 - 这样语义清晰、调试方便，且所有 CTE 都在同一个
WITH块内，数据库优化器更容易处理
复杂点永远在 anchor 的准确性——递归跑得再快，起点错了整条链就偏了。别省那一步验证。
