MySQL 8.0中WITH RECURSIVE查询组织架构必须严格采用“锚点+递归成员”两段式结构，用UNION ALL连接，递归引用仅允许在FROM/JOIN中出现；常见错误包括锚点条件不匹配、数据自环、未设level限制导致超1000次迭代中止。
MySQL 8.0 中 WITH RECURSIVE 查询组织架构的正确写法
MySQL 8.0+ 原生支持递归 CTE，但必须严格满足“锚点 + 递归成员”的两段式结构，且递归引用只能出现在 UNION ALL 右侧。常见错误是把条件写在递归部分的 WHERE 里却忘了限制层级或闭环，导致无限循环或查询超时。
假设表 org_dept 结构为：id（部门ID）、name（部门名）、parent_id（上级部门ID，根节点为 NULL 或 0）：
WITH RECURSIVE dept_tree AS ( -- 锚点：从根部门开始（这里假设根部门 parent_id IS NULL） SELECT id, name, parent_id, 0 AS level FROM org_dept WHERE parent_id IS NULL <p>UNION ALL</p><p>-- 递归成员：关联下级 SELECT d.id, d.name, d.parent_id, dt.level + 1 FROM org_dept d INNER JOIN dept_tree dt ON d.parent_id = dt.id ) SELECT * FROM dept_tree ORDER BY level, id;
为什么查询卡住或报错 Recursive query aborted after 1001 iterations
这是 MySQL 的默认递归深度保护机制触发了。不是数据量大，而是 CTE 没能自然终止——最常见原因有三个：
- 锚点选错：比如根节点实际用的是
parent_id = 0，但锚点写了IS NULL，导致无初始行，递归体又无法匹配，某些旧版本会异常循环 - 自环或脏数据：某条记录的
parent_id指向自己，或形成 A→B→C→A 循环，递归永远收不回来 - 没加层级限制：生产环境树可能很深，应显式加
level 防御，例如在递归 <code>SELECT后加WHERE dt.level
调试时可先加 SELECT id, parent_id, level 看前几层输出，确认路径是否符合预期。
查某个部门的所有上级（向上遍历）怎么写
和向下查子部门方向相反，关键在连接条件和锚点选择：锚点是目标部门本身，递归时往上找 parent_id 对应的父部门。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
例如查 id = 123 的所有上级（含自己），按从上到下顺序排列：
WITH RECURSIVE dept_path AS ( -- 锚点：从目标部门开始 SELECT id, name, parent_id, 0 AS level FROM org_dept WHERE id = 123 <p>UNION ALL</p><p>-- 递归：找当前行的 parent_id 对应的部门 SELECT d.id, d.name, d.parent_id, dp.level + 1 FROM org_dept d INNER JOIN dept_path dp ON d.id = dp.parent_id ) SELECT * FROM dept_path ORDER BY level DESC;
注意：这里 INNER JOIN 条件是 d.id = dp.parent_id，不是反过来；否则逻辑颠倒。如果根节点 parent_id 是 0 而非 NULL，锚点后的 WHERE 和递归中的 ON 都要同步适配。
性能与索引注意事项
递归 CTE 本质是多次等值连接，没有索引会全表扫描每次递归，N 层就扫 N 次表。必须确保 parent_id 字段有索引：
- 执行
SHOW INDEX FROM org_dept确认parent_id列存在索引（哪怕只是普通 INDEX，非必须 UNIQUE） - 如果经常按不同起点查，考虑联合索引：
INDEX (parent_id, id)，让递归连接时能覆盖查询 - 避免在递归成员中使用函数包裹字段，如
IFNULL(d.parent_id, 0) = dt.id，会导致索引失效
另外，WITH RECURSIVE 不支持 ORDER BY 在 CTE 定义内使用（除窗口函数外），排序必须放在最终 SELECT 外层。
