MySQL CTE 递归查询为什么会提前停止：锚点、递归成员与 cte_max_recursion_depth

组织树查询少了一层、日期序列只返回前几天时，先别急着把问题归到 MySQL 优化器。递归 CTE 的结果是由锚点成员（anchor）、递归成员（recursive member）和终止条件共同决定的，另外还会受到会话变量 cte_max_recursion_depth 的保护。把这三处逐个核对，通常能很快分清是条件提前收敛，还是深度上限真正介入。

递归查询“提前停止”首先看递归成员还能不能产生新行，再看深度上限；不要只调大 cte_max_recursion_depth，否则可能把无终止条件的问题放大。

少一层结果时，先把递归 CTE 拆成两段

下面用一个最小整数序列复现。锚点成员返回 1，递归成员从上一行的 n 加 1，只在 n 时继续：

WITH RECURSIVE seq (n) AS (
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM seq WHERE n 

结果应为 1 到 5。关键在于条件检查的是当前行：当递归成员拿到 5 时，n 不成立，于是不会再生成 6，但 5 本身已经由上一轮生成并保留。若把条件写成 n ，结果自然只到 4，这不是查询引擎漏行。

递归成员为什么没有产生下一行

检查终止条件是不是提前挡住了边界

排查时先把递归成员单独改成可读的判断。日期序列常见写法是 current_date ，但如果列是 DATETIME，或者业务要包含结束日，就要明确比较的是日期还是时间。组织树则经常把“当前节点的父级”与“下一层的子级”写反。

可以先把边界列带出来，不要只看最终的业务字段：

WITH RECURSIVE tree (category_id, parent_id, depth) AS (
  SELECT category_id, parent_id, 0
  FROM product_category
  WHERE category_id = 10
  UNION ALL
  SELECT c.category_id, c.parent_id, t.depth + 1
  FROM product_category AS c
  JOIN tree AS t ON c.parent_id = t.category_id
  WHERE t.depth 

这个查询只允许从根节点向下展开三层。若根节点有子节点但结果停在 0 层，优先核对 JOIN c.parent_id = t.category_id 是否与表中的父子方向一致；若停在 3 层，则条件就是预期的保护边界。

确认锚点的列类型没有把递归值截断

递归 CTE 的列类型由锚点部分确定。锚点如果返回了过窄的字符类型，后续递归拼接路径时可能出现数据过长错误；数值列也应让锚点和递归成员保持兼容。调试阶段把列名显式写在 CTE 后面，并让锚点直接投影出 depth，比依赖隐式别名更容易核对。

出现递归深度错误时，不要只改全局变量

MySQL 8.4 手册说明，cte_max_recursion_depth 限制 CTE 的递归层数，默认值为 1000；超过限制时语句会被终止。它是防护栏，不是终止条件。开发环境可以用会话级设置做受控验证：

SET SESSION cte_max_recursion_depth = 20;

WITH RECURSIVE seq (n) AS (
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM seq
)
SELECT n FROM seq;

这个故意没有终止条件的例子应该被深度上限挡住。生产查询更稳妥的组合是：递归成员写业务边界，必要时再给查询设置 MAX_EXECUTION_TIME，并通过监控观察错误而不是盲目把全局值调大。

cte_max_recursion_depth 是会话变量，验证完要确认连接池不会把临时设置带到下一次业务请求。对于层级数据，还应限制最大业务深度，并对环形父子关系做数据校验；否则递归即使没有立刻报错，也会消耗大量临时表空间。

回到真实层级表做一次可回滚核对

把最小序列跑通后，再在只读会话中查询 product_category。先记录根节点、期望层数和返回行数，再逐步放宽 t.depth 。每次只改一个条件，避免同时改连接方向和深度上限，导致结果无法解释。

如果扩大深度后行数突然暴涨，先查是否存在环：同一个 category_id 是否最终又能沿 parent_id 回到自己。若是导入数据造成的环，应先修复数据并在事务中复核；不要用无限提高深度的方式掩盖它。

常见问题：递归 CTE 的边界怎么判断

为什么递归条件写成 n

因为 5 是上一轮递归成员生成的结果，条件只决定是否从 5 继续生成下一行，所以最终结果包含 5，不包含 6。

调大 cte_max_recursion_depth 就能解决少返回几层吗？

不能。只有错误明确来自递归深度限制时它才相关；如果 JOIN 方向或 WHERE 边界错误，调大上限不会生成正确的子节点。

递归查询怎样避免无限循环？

同时设置业务深度上限、数据层面的环检测和查询时间限制。先让查询可控，再根据真实最大层级调整会话级深度，而不是直接修改全局值。

把一次排查结果留成可复用检查清单

• 锚点是否返回了正确的根行或初始序列。
• 递归成员的连接方向是否从上一层指向下一层。
• 终止条件是否覆盖期望的最后一层，而不是提前一层。
• cte_max_recursion_depth 是否只在当前会话受控调整，并配合超时。
• 真实表中是否存在自环、互环或异常的空父级。

把这五项和一次最小复现 SQL 一起放进故障记录，下一次遇到“少一层”时，通常不需要从执行计划或全局配置开始猜。