mysql 8.0.1+才支持with recursive，5.7及以下版本会报error 1064；不可在函数中使用，需改用存储过程、应用层实现或预计算路径；性能优化首选为parent_id加索引。
MySQL 8.0+ 才支持递归 CTE，别在 5.7 里硬写 WITH RECURSIVE
MySQL 原生递归查询只从 8.0.1 版本开始支持 WITH RECURSIVE，如果你用的是 5.7 或更早版本，WITH RECURSIVE 会直接报错 ERROR 1064 (42000)。这不是语法写错了，是版本不支持。强行用存储函数模拟递归（比如用临时表+循环）不仅性能差、并发不安全，还容易栈溢出或死循环——尤其当组织树存在环（比如 A→B→A）时，根本停不下来。
用 WITH RECURSIVE 查子部门全路径最简写法
假设表 dept 结构为：id、name、parent_id（根节点 parent_id 为 NULL 或 0），要查 ID=5 的部门及其所有下级（含自己），直接用：
WITH RECURSIVE dept_tree AS ( SELECT id, name, parent_id, 0 AS level FROM dept WHERE id = 5 UNION ALL SELECT d.id, d.name, d.parent_id, dt.level + 1 FROM dept d INNER JOIN dept_tree dt ON d.parent_id = dt.id ) SELECT * FROM dept_tree ORDER BY level;
注意点：
-
UNION ALL必须写，UNION会去重但拖慢速度，且可能误删合法重复数据 - 起始查询（anchor member）不能带循环引用逻辑，否则递归无法终止
-
MAX_RECURSION_DEPTH默认是 1000，超深树要先设：SET SESSION cte_max_recursion_depth = 2000;
想封装成函数？MySQL 不允许函数里用 WITH RECURSIVE
MySQL 函数（CREATE FUNCTION）体内禁止执行包含 WITH RECURSIVE 的查询，会报 ERROR 1356 (HY000)：“View 'xxx' references invalid table(s) or column(s)”。这不是权限问题，是语法限制。真要复用逻辑，只能：
- 改用存储过程（
CREATE PROCEDURE），用OUT参数或临时表返回结果 - 把递归逻辑写在应用层（如 Python/Java），分页拉取，控制深度
- 预计算路径字段（如
path存 "1/3/5/12"），用字符串匹配替代递归（适合读多写少）
硬套函数只会卡在语法校验阶段，连创建都失败。
递归查询性能差？加索引比改写法更有效
慢通常不是因为用了递归，而是没索引。确保 dept(parent_id) 有单列索引，如果常按 parent_id 查子节点，这个索引能直接让递归每层下降变快。另外，避免在递归 CTE 里 JOIN 大表或加复杂 WHERE——这些该放到外层查询做：
-- ✅ 好：过滤放外面 WITH RECURSIVE t AS (...) SELECT * FROM t WHERE status = 1; <p>-- ❌ 差：过滤放里面，每层都执行 WITH RECURSIVE t AS ( SELECT ... FROM dept WHERE status = 1 -- 每次递归都扫全表 UNION ALL SELECT ... FROM dept d JOIN t ON ... WHERE d.status = 1 )</p>
组织架构树一旦超过 5000 节点，再好的递归写法也会明显延迟，这时候该考虑缓存或前端懒加载了。
