不能直接用join实现无限级树,因join仅支持固定深度(如三级需写三次join),无法应对动态层级;mysql 5.7及更早不支持with recursive,8.0+才引入递归cte,且自连接无法生成可排序路径、易漏数据、不兼容聚合与索引。

为什么不能直接用 JOIN 实现无限级树?
MySQL 没有原生的递归 CTE(直到 8.0 才支持),5.7 及更早版本连 WITH RECURSIVE 都不识别。你写 WITH RECURSIVE t AS (...) 会直接报错 ERROR 1064 (42000)。即使在 MySQL 8.0+,自连接本身也不等于递归查询——单纯多层 JOIN 只能查固定深度(比如三级就写三次 JOIN),无法应对“某节点下有 5 级子节点”这种动态场景。
MySQL 8.0+ 正确做法:用 WITH RECURSIVE 构建路径
核心是把树结构转为带层级和路径的扁平结果。假设表 categories 有 id、name、parent_id 字段:
WITH RECURSIVE tree AS ( SELECT id, name, parent_id, 0 AS level, CAST(id AS CHAR(1000)) AS path FROM categories WHERE parent_id IS NULL -- 根节点 UNION ALL SELECT c.id, c.name, c.parent_id, t.level + 1, CONCAT(t.path, '-', c.id) FROM categories c INNER JOIN tree t ON c.parent_id = t.id ) SELECT * FROM tree ORDER BY path;
注意点:
-
CAST(id AS CHAR(1000))是必须的——递归 CTE 要求所有分支的列类型一致,否则报错ERROR 1250 (HY000): Table 'tree' has different number of columns -
path字段用于排序保证树形顺序,也方便前端解析层级 - 若要查某个节点的所有祖先,把
UNION ALL方向反过来(从子往父递归),起始条件改为WHERE id = ?
MySQL 5.7 或更低版本:用闭包表或路径枚举替代
硬写自连接查多级只会让 SQL 膨胀且不可维护。真实项目中更推荐两种方案:
-
路径枚举(Path Enumeration):在原表加一个
path字段,存类似'/1/5/12/'的字符串,用LIKE '/1/%'查子树,用SUBSTRING_INDEX解析父级 -
闭包表(Closure Table):额外建一张
category_closure表,字段为ancestor_id、descendant_id、depth,每次插入节点时预计算并写入所有祖先-后代关系。查子树变成简单SELECT descendant_id FROM category_closure WHERE ancestor_id = ?
两者都牺牲写性能换读性能,但比拼接 N 层 LEFT JOIN 更可靠、可索引、易维护。
自连接写法只适用于明确的固定层级
比如查“一级分类 → 二级分类 → 三级分类”的三元组,可以用三层 JOIN:
SELECT lv1.name AS level1, lv2.name AS level2, lv3.name AS level3 FROM categories lv1 LEFT JOIN categories lv2 ON lv2.parent_id = lv1.id LEFT JOIN categories lv3 ON lv3.parent_id = lv2.id WHERE lv1.parent_id IS NULL;
但要注意:
- 必须用
LEFT JOIN,否则没有三级子类的二级类会被过滤掉 - 无法区分“该节点是叶子还是中间节点”,需额外判断
lv3.id IS NULL - 一旦需求变成“最多五级”,SQL 就得重写,且性能随层级指数下降
真正需要动态深度时,别试图靠改 JOIN 次数解决——要么升级到 MySQL 8.0+ 用递归 CTE,要么换存储模型。路径和闭包表不是“退而求其次”,而是面对无递归引擎时的合理设计选择。











