因为树形结构具有无限递归特性，传统JOIN只能固定连接层数，无法动态展开未知深度的父子关系，必须依赖WITH RECURSIVE等数据库原生递归机制才能完整查询整棵树。
为什么直接用 JOIN 无法查出完整树形路径
因为树形结构是递归的，上级可能有多个下级，下级又可能有自己的下级，传统 JOIN 只能固定层数（比如两层 JOIN 查到孙级），一旦层级变深或不固定，SQL 就会写不下去。这时候必须依赖数据库对递归的支持，而不是靠子查询硬拼。
注意：标准 SQL 的普通子查询（非递归）根本不能实现“查出整棵树”或“查出某节点所有祖先/后代”——它只能返回一个标量、一行或多行结果，但无法逐层展开关系链。
- 想查“张三的所有下属（含间接）”，需要从张三开始，一层层找
manager_id = 张三.id，再找这些人的下属……这是典型的递归问题 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持
WITH RECURSIVE，这是唯一靠谱方案；5.7 或更早 MySQL 只能靠程序循环或自连接模拟，且最多写死 5 层 - 误用普通子查询（如
WHERE id IN (SELECT ...)）只能查直接下级，不是树形查询
MySQL 8.0+ 怎么用 WITH RECURSIVE 查所有下级
核心是定义锚点（起始节点）和递归成员（找下一级），数据库自动迭代直到无新记录。以下查 id = 1 的所有下属（含间接）：
WITH RECURSIVE org_tree AS ( -- 锚点：起始员工 SELECT id, name, manager_id, 0 AS level FROM employees WHERE id = 1 <p>UNION ALL</p><p>-- 递归：找当前结果集中所有人的直接下属 SELECT e.id, e.name, e.manager_id, ot.level + 1 FROM employees e INNER JOIN org_tree ot ON e.manager_id = ot.id ) SELECT * FROM org_tree ORDER BY level;
-
UNION ALL是必须的，UNION会去重并拖慢性能，而树形结构天然无重复 ID - 别名
org_tree在递归部分被引用，MySQL 要求递归引用必须在FROM或JOIN中，不能在WHERE子句里写id IN (SELECT ... FROM org_tree) - 如果漏写
level字段，虽然语法通过，但你将无法判断层级深度，也难控制最大递归深度
PostgreSQL 和 SQL Server 的写法差异在哪
逻辑一致，但细节有坑：
- PostgreSQL 要求递归查询中，锚点和递归分支的列数、类型、顺序必须严格一致；MySQL 宽松些，但列名以锚点为准
- SQL Server 用
CTE同样支持WITH RECURSIVE（2017+），但默认递归上限是 100 层，超限报错Msg 530, Level 16, State 1: The statement terminated. The maximum recursion 100 has been exhausted，需加OPTION (MAXRECURSION 32767) - PostgreSQL 没内置层数限制，但可通过
WHERE level < 10主动截断，防止无限循环（比如数据里出现id=5, manager_id=5的脏数据）
没有 WITH RECURSIVE 怎么临时应对（如 MySQL 5.7）
只能用有限层数的 LEFT JOIN 拼接，或者用程序查多次。例如查最多 3 层下属：
SELECT a.id AS emp_id, a.name AS emp_name, b.id AS mgr_id, b.name AS mgr_name, c.id AS mgr2_id, c.name AS mgr2_name FROM employees a LEFT JOIN employees b ON a.manager_id = b.id LEFT JOIN employees c ON b.manager_id = c.id WHERE a.id = 1 OR b.id = 1 OR c.id = 1;
- 这种写法本质是“展开图”，不是真正树形查询：它返回的是扁平化路径，无法按树结构排序，也不能动态扩展层级
- WHERE 条件必须覆盖所有可能位置（本人、上级、上上级），否则会漏数据
- 字段名容易冲突（比如多个
name），必须用别名区分，否则客户端取值会混乱
真要可靠处理树形结构，升级数据库或改用程序端递归才是正解。硬靠子查询兜底，只会让逻辑越来越难维护。
