普通子查询无法实现真正的树形遍历，因其无递归能力、只能查固定深度；必须用WITH RECURSIVE（MySQL 8.0+等）或数据库特有语法（如Oracle CONNECT BY）才能处理任意层级父子关系。
直接用子查询无法实现真正的树形遍历——它没有递归能力，只能查固定深度。真要查任意层级的父子关系，必须用 WITH RECURSIVE（MySQL 8.0+、PostgreSQL、SQL Server）或数据库特有语法（如 Oracle 的 CONNECT BY）。
为什么普通子查询撑不住树形查询
子查询每次执行只返回一个结果集，不能“自己调自己”。比如你想查 ID=5 的所有祖先，得先找它的 parent_id，再找那个 parent_id 的 parent_id……这个链式查找没法靠一层层嵌套子查询写死——深度一变就崩，而且 SQL 标准不支持无限嵌套。
- 常见错误现象：
Operand should contain 1 column(s)或查询超时，本质是强行用 JOIN 模拟递归，但写了 5 层后第 6 层数据就漏了 - 使用场景：仅适用于明确知道最多 2–3 层的静态结构（如省-市-区三级表），且每级都单独建表
- 性能影响：N 层嵌套 = N 次 JOIN，数据量稍大就触发笛卡尔积风险，
EXPLAIN显示 rows 指数级增长
用 WITH RECURSIVE 替代子查询的实操要点
递归 CTE 才是查动态树的正解。它分两块：锚点（起点） + 递归体（自己 JOIN 自己），由数据库引擎控制终止条件。
- 锚点必须非空：比如查某节点的所有后代，锚点写
WHERE id = 5；查整棵树，锚点写WHERE parent_id IS NULL - 递归体的 JOIN 条件必须让结果收敛：向上查祖先用
c.id = t.parent_id，向下查子孙用c.parent_id = t.id - 务必加
level字段：既可排序，也能防死循环（加WHERE t.level < 10） - MySQL 8.0+ 默认递归深度 1000，超深组织架构需显式设
SET cte_max_recursion_depth = 5000
示例：查员工 ID=4 的所有上级（向上递归）
WITH RECURSIVE org_up AS ( SELECT id, name, manager_id, 0 AS level FROM employees WHERE id = 4 UNION ALL SELECT e.id, e.name, e.manager_id, u.level + 1 FROM employees e INNER JOIN org_up u ON e.id = u.manager_id ) SELECT * FROM org_up;
当数据库不支持 WITH RECURSIVE 怎么办
MySQL 5.7 或更老版本、某些嵌入式 SQLite 场景下，WITH RECURSIVE 不可用。这时别硬套子查询，改用两种务实方案：
- 应用层递归：一次性查出全量树数据（
SELECT * FROM employees），在 Java/Python 里用 Map 构建父子映射，再 DFS/BFS 遍历——比反复查库快得多 - 存储过程模拟：用游标 + 临时表迭代收集，但要注意 MySQL 存储过程无法直接返回结果集，得配合临时表或 JSON 拼接
- 拒绝“伪递归”：网上那些用
FIND_IN_SET+ 自定义函数拼字符串的方案，数据一过万就卡死，且无法做聚合（如统计每个部门总人数）
真正麻烦的不是语法怎么写，而是递归查询默认不带聚合能力——想算某个节点下所有子孙的 salary 总和，得先查出完整子树，再用窗口函数或二次 JOIN 汇总，这一步容易被忽略。
