MySQL 递归 CTE 遍历树数据时怎么防止无限循环

用 WITH RECURSIVE 遍历组织、目录或分类树时，真正可靠的做法不是只把递归深度调大，而是同时做三件事：在路径中记录已经访问过的节点，递归条件里拒绝重复节点，再设置一个符合业务的最大深度。这样即使 parent_id 被错误地改成闭环，查询也会停在可解释的边界内。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/with.html

先把无限循环拆成重复访问和异常深度

假设层级表名为 category_node，关键字段如下：

树数据的正常分支可以很深，但一个节点不应该在同一条祖先路径上再次出现。只用 depth 能挡住长链，却不能说明哪一条引用形成了环；只用 UNION DISTINCT 也不稳妥，因为结果行里若包含不同的 path 或 depth，它们仍可能被视为不同记录。

用路径字段阻止节点再次进入递归

下面的写法适合节点 id 为整数、路径规模可控的场景。锚点部分先取根节点，递归部分只连接当前节点的子节点，并用 FIND_IN_SET 判断子节点是否已在路径中。

WITH RECURSIVE node_tree (id, name, parent_id, depth, path) AS (
    -- 锚点：从根节点开始，并把根 id 放入已访问路径
    SELECT
        n.id,
        n.name,
        n.parent_id,
        0 AS depth,
        CAST(n.id AS CHAR(200)) AS path
    FROM category_node AS n
    WHERE n.parent_id IS NULL

    UNION ALL

    -- 递归：只接收未出现在当前路径中的子节点
    SELECT
        child.id,
        child.name,
        child.parent_id,
        tree.depth + 1,
        CONCAT(tree.path, ',', child.id)
    FROM node_tree AS tree
    JOIN category_node AS child
      ON child.parent_id = tree.id
    WHERE tree.depth 

这里的关键不是字符串拼接本身，而是递归成员的两个门槛：tree.depth 给异常长链一个业务上限，FIND_IN_SET(...) = 0 拒绝当前路径已经出现过的节点。若存在 A→B→A，走到 B 时，A 已经在 path 中，A 就不会再次生成。

路径列由非递归的第一段 SELECT 决定类型和宽度。节点数量多、id 较长时，要把 CHAR(200) 换成足够大的类型；否则严格模式下可能出现数据过长错误，非严格模式也可能得到被截断的路径。若数据规模更大，可以改用 JSON 数组记录访问集合，再用 JSON 函数判断成员，但仍要保留深度上限。

再用服务器限制兜底，别把它当成业务逻辑

路径判重解决的是“当前路径是否回到旧节点”，但生产环境仍需要资源保护。开发或排障时可以先把限制收紧：

-- 会话级限制只影响当前连接，便于排查异常递归
SET SESSION cte_max_recursion_depth = 100;
SET SESSION max_execution_time = 1000;

WITH RECURSIVE node_tree (id, depth) AS (
    -- 锚点：从指定根节点开始
    SELECT id, 0
    FROM category_node
    WHERE id = 1

    UNION ALL

    -- 递归：深度上限和查询级行数上限共同限制异常数据
    SELECT child.id, tree.depth + 1
    FROM node_tree AS tree
    JOIN category_node AS child ON child.parent_id = tree.id
    WHERE tree.depth 

cte_max_recursion_depth 限制递归层数，max_execution_time 或 MAX_EXECUTION_TIME 限制查询时间，递归段的 LIMIT 限制生成的行数。它们的职责是“出了问题尽快停”，不是替代 FIND_IN_SET 这样的数据正确性检查。正式查询中还应记录被截断的根节点和深度，便于回头修复闭环数据，而不是默默把异常当成空结果。

常见问题

只加 cte_max_recursion_depth 可以吗？

不建议。它只能限制递归层数，不能指出具体哪个节点重复；而且调大这个值会扩大错误查询的资源消耗。优先在 CTE 内做路径判重，再按业务设置会话级上限。

为什么用了 UNION DISTINCT 仍可能绕圈？

去重比较的是完整结果行。如果每次回到同一节点时 path、depth 或其他列不同，行就不相同，不能依靠集合去重发现环。

FIND_IN_SET 很慢怎么办？

它适合中小规模、路径长度可控的遍历。数据量明显增大时，可将闭环检查前移到写入校验，或改用 JSON 访问集合、闭包表等模型；无论采用哪种模型，都要保留递归深度和执行时间保护。

排查递归 CTE 时，可以按“先看 parent_id 是否成环，再看路径是否判重，最后看深度和资源限制”的顺序处理。这样既能让正常树分支完整返回，也能让脏数据在可控范围内停止。