MySQL WITH RECURSIVE 递归查询怎么防止死循环：终止条件、深度上限与结果核对

组织架构表里一旦出现“部门 A 的上级是 B，B 又绕回 A”，MySQL 的 WITH RECURSIVE 就可能沿着环路持续展开，直到触发递归深度限制或查询超时。稳妥的写法不是只把层数上限调大，而是同时准备明确的终止条件、深度护栏和路径去重检查。

先把递归范围限定在一棵树里

下面的示例表保存部门编号和直属上级编号。真实项目中，导入脚本或人工修数据都可能让 parent_id 形成环。

CREATE TABLE org_unit (
  unit_id BIGINT PRIMARY KEY,
  parent_id BIGINT NULL,
  unit_name VARCHAR(80) NOT NULL,
  KEY idx_org_parent (parent_id)
);

查询某个根部门的所有下级时，锚点成员先放入根节点，递归成员只沿 parent_id = unit_id 向下找。边界也要写在查询里，避免把整张表误展开。

WITH RECURSIVE org_tree AS (
  SELECT unit_id, parent_id, unit_name,
         0 AS depth,
         CAST(unit_id AS CHAR(2000)) AS path
  FROM org_unit
  WHERE unit_id = 10

  UNION ALL

  SELECT child.unit_id, child.parent_id, child.unit_name,
         tree.depth + 1,
         CONCAT(tree.path, ',', child.unit_id)
  FROM org_unit AS child
  JOIN org_tree AS tree ON child.parent_id = tree.unit_id
  WHERE tree.depth 

这里的 depth 是事故隔离线，不是业务上的“最多五十层”结论。组织树理论上应该很浅，超过这个值更适合进入数据修复流程。

终止条件和深度上限分别解决什么问题

终止条件负责正常收敛

当某个节点没有子节点时，递归成员自然找不到新行，结果就结束。若业务还要过滤停用部门，应把这个规则放在递归成员的连接条件或筛选条件中，并确认不会意外截断有效子树。

深度上限负责兜底

环路数据不会因为“树应该有叶子”而自动消失。深度护栏能让查询在有限步内结束，但它可能留下一个看起来正常的截断结果，所以必须把最大深度暴露给后续检查。

SELECT MAX(depth) AS max_depth,
       COUNT(*) AS row_count,
       COUNT(DISTINCT unit_id) AS distinct_units
FROM org_tree;

用路径检查节点是否重新出现

上面的 path 让每一行都带着从根节点走过的编号。继续递归前，可以判断子节点编号是否已经出现在路径中；出现时停止这条分支，而不是再次加入同一个节点。

WITH RECURSIVE org_tree AS (
  SELECT unit_id, parent_id, unit_name, 0 AS depth,
         CONCAT(',', unit_id, ',') AS path,
         0 AS cycle_found
  FROM org_unit
  WHERE unit_id = 10

  UNION ALL

  SELECT child.unit_id, child.parent_id, child.unit_name,
         tree.depth + 1,
         CONCAT(tree.path, child.unit_id, ','),
         INSTR(tree.path, CONCAT(',', child.unit_id, ',')) > 0
  FROM org_unit AS child
  JOIN org_tree AS tree ON child.parent_id = tree.unit_id
  WHERE tree.depth 

编号两侧的逗号不能省略。直接查找字符串 1 会把 11 误认为命中，这是路径判断里很隐蔽的假阳性。

查询返回后还要做三项核对

1. 核对根节点是否唯一：锚点条件若过宽，递归结果从一开始就不是一棵树。
2. 核对 MAX(depth)：总是贴着 50，通常说明数据或连接方向有问题。
3. 核对 COUNT(*) 与 COUNT(DISTINCT unit_id)：差值提示同一节点通过多条路径到达，需要确认业务是否允许。

如果需要定位脏数据，可以先用小范围根节点运行，把 path 导出到临时表，再按逗号分隔路径复核。不要为了让页面尽快有结果，直接删掉深度限制。

常见问题

MySQL 会自动识别递归 CTE 的环吗？

不要把自动停止当作环检测。应由查询显式设置深度护栏，并按业务需要记录路径或访问集合。

深度限制应该设置多大？

按业务允许的最大层级设置，再留出很小的异常缓冲。组织架构、评论回复和分类树的合理深度不同，不能照搬一个固定数字。

为什么结果行数比节点数多？

可能是一个节点从多个父级路径到达，也可能是连接条件过宽。先对照 COUNT(DISTINCT unit_id) 和 path，再决定是合法 DAG 还是脏数据。

把递归查询当成可观测的流水线

一条可靠的递归查询至少有四个可检查的阶段：锚点限定范围、递归成员沿正确方向连接、深度和路径阻断异常、结果统计揭示截断或重复。这样即使数据暂时不干净，查询也能有限结束，排查结果也不会被“返回了几行”误导。