MySQL 8.0+向下查所有下属的典型递归查询：锚点选WHERE manager_id = ?获取直接下属，递归步用JOIN employees e ON e.manager_id = s.id向下延伸，并加WHERE s.depth < N防环；必须用UNION ALL、显式depth字段和合适索引。

MySQL 8.0+ 的 WITH RECURSIVE 确实是处理组织架构查询的利器，但用之前得想清楚几个前提：你是要向上查领导链，还是向下挖团队树？数据结构本身有没有循环？如果不手动加上深度限制，很容易一脚踩进死循环或者查出重复路径的坑里。

怎么写向下查所有下属的递归查询

这个场景很典型：给定一个经理的ID，把他手下直接汇报的、间接汇报的所有下属都找出来。核心思路在于，锚点部分锁定“直接下属”，递归部分则顺着 manager_id 的指向一层层往下钻：

• 锚点部分：用 WHERE manager_id = ? 精准抓取第一层下属，这是递归的起点。
• 递归部分：关键连接条件是 JOIN employees e ON e.manager_id = s.id。这里方向千万别搞反了，是下一层员工的 manager_id 去匹配上一层结果的 id。
• 安全防护：必须加上终止条件，比如 WHERE s.id IS NOT NULL，或者更直观地，显式限制 depth < 10，防止数据结构有环导致查询无限进行。
• 集合操作：优先使用 UNION ALL。用 UNION 虽然能去重，但额外开销大，在递归场景下，UNION ALL 性能更好，结果也更可控。

WITH RECURSIVE subordinates AS (
  SELECT id, name, manager_id, 1 AS depth
  FROM employees
  WHERE manager_id = 4  -- 锚点：查ID为4的人的所有下属
  UNION ALL
  SELECT e.id, e.name, e.manager_id, s.depth + 1
  FROM employees e
  INNER JOIN subordinates s ON e.manager_id = s.id
  WHERE s.depth < 5  -- 显式深度保护
)
SELECT * FROM subordinates ORDER BY depth, id;

怎么查某员工到CEO的完整上级路径

向上追溯领导链，可以说是 WITH RECURSIVE 最“本分”的用法了：方向单一、通常无环、终点明确（根节点的 manager_id 为 NULL）。思路正好反过来，锚点是员工自己，递归步是不断向上找他的经理：

• 锚点选择：这次用 WHERE id = ? 定位到起始员工本人，而不是他的经理ID。
• 递归关联：连接条件变为 JOIN employees e ON e.id = p.manager_id，意思是用当前行的 manager_id 去找到对应的上级记录。
• 终止控制：通过 WHERE p.manager_id IS NOT NULL 来确保查到顶层（经理为NULL）后就停止，避免无意义的继续查找。
• 路径构建：如果想用 CONCAT 拼出完整路径，注意初始值的类型要和后续拼接保持一致，比如都转换为 CHAR 类型，否则可能会报错。

WITH RECURSIVE path_to_top AS (
  SELECT id, name, manager_id, 0 AS depth, CAST(name AS CHAR(200)) AS path
  FROM employees
  WHERE id = 6  -- 锚点：从员工ID6开始
  UNION ALL
  SELECT e.id, e.name, e.manager_id, p.depth + 1, CONCAT(e.name, ' → ', p.path)
  FROM employees e
  INNER JOIN path_to_top p ON e.id = p.manager_id
  WHERE p.manager_id IS NOT NULL
)
SELECT * FROM path_to_top ORDER BY depth DESC;

为什么查出来有重复ID或深度错乱

很多人写完查询，会发现结果里同一个人出现了好几次，深度字段跳来跳去，或者路径莫名其妙分叉了。这其实不怪语法，根源在于 MySQL 的 WITH RECURSIVE 实现得非常“基础”——它只管递归，不管去重、排序和剪枝，所有逻辑约束都得靠你自己在SQL里写明：

• UNION ALL 不去重：如果数据本身允许一个人有多个上级（比如矩阵式管理），递归就会沿着不同路径重复找到同一个人。业务上最好能保证 (id, manager_id) 组合的唯一性，或者建立相应的唯一索引。
• 递归部分限制多：在递归部分的子查询里，你不能使用 ORDER BY 或 LIMIT，否则会直接报语法错误。控制递归深度，只能依赖 WHERE 条件，比如前面提到的 depth < 10。
• 顺序不可控：如果你不在CTE里显式定义并计算一个 depth 字段，结果的返回顺序基本上是随机的，看起来就是乱的。所以，务必在查询中把这个字段算出来并暴露给外层用于排序。
• 默认深度限制：MySQL默认的递归最大深度是1000层，超过就会抛出 ERROR 3636。临时调大可以执行：SET SESSION cte_max_recursion_depth = 2000;，但别滥用。

性能和索引怎么优化

递归查询跑得慢，十有八九不是语句写错了，而是底层缺了合适的索引支撑：

• 索引是必须的：根据查询方向创建针对性的联合索引。向下查下属，就建 INDEX idx_mgr_id (manager_id, id)；向上查领导，则建 INDEX idx_id_mgr (id, manager_id)。
• 避免函数操作：在递归部分的连接或过滤条件里，尽量避免对CTE的字段进行函数操作（例如 WHERE UPPER(s.name) = 'X'），这会让索引失效。
• 预过滤数据：当数据量很大时，可以在锚点和递归部分的子查询里先加上业务过滤条件，比如 WHERE status = 'active'，减少每一层需要处理的数据量。
• 谨慎调整递归深度：把 cte_max_recursion_depth 调得过高可能会耗尽服务器内存。生产环境建议保持默认或小幅增加，千万不要图省事设为0（无限制）。

说到底，写出一个能跑的递归查询并不算难。真正的挑战在于，你是否清楚自己的组织架构数据里有没有隐藏的循环引用？是否允许一个员工向多人汇报？业务上是要穷举所有路径，还是只要最短路径？——想明白这些问题，才能决定你是该继续用 WITH RECURSIVE，还是该考虑换用 Neo4j 这类图数据库，或者干脆把递归逻辑放到应用层去处理。