当前位置：首页 > 文章列表 > 数据库 > MySQL > 递归 CTE 终止条件怎么配置或排查

递归 CTE 终止条件怎么配置或排查

来源：17golang原创 2026-09-13 09:01:27 0浏览收藏

MySQL 递归 CTE 的终止条件，首先要写在递归成员的查询里，让每一轮数据朝着明确的终点推进；外层 SELECT 的 WHERE 只能过滤最终结果，不能保证递归过程提前停止。排查“不退出”或“多一行”时，先看这个条件，再看服务端的递归深度和超时保护。

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

要点速览

锚点 SELECT 负责起点，递归 SELECT 负责产生下一轮并决定何时不再产生新行。
cte_max_recursion_depth、max_execution_time 和递归成员中的 LIMIT 是安全阀，不是业务终止逻辑。
把递归深度、执行耗时和最终边界分别记录，通常比直接调大全局参数更快定位问题。

先确认递归成员真的在向终点前进

一个可控的递归 CTE 至少有三个要素：锚点行、递归成员和收敛条件。以生成日期为例，锚点从起始日期开始，递归成员每天加一天，dt 保证下一轮最终没有新行。这里使用小于号，是因为希望包含结束日期但不生成结束日期之后的日期。

MySQL 递归 CTE 中锚点、递归成员、日期列和终止条件的查询结构框图 — 图1：MySQL 递归 CTE 的静态查询结构示意，锚点产生起点，递归成员依据日期列和 WHERE 条件收敛。

WITH RECURSIVE day_list (dt) AS (
    -- 锚点只生成起始日期，决定 dt 的类型和初始值
    SELECT DATE('2026-01-01')
    UNION ALL
    -- 每轮向结束日期推进一天，不能让 dt 原地不变
    SELECT dt + INTERVAL 1 DAY
    FROM day_list
    -- 结束日期需要包含在结果中，所以这里限制“当前日期小于结束日期”
    WHERE dt

最常见的两个错误正好相反：写成 dt 往往会多生成一行，写成固定不变的 SELECT dt 则永远不会收敛。层级表也一样，应该让 depth 增加，或让路径集合排除已经访问过的节点；不要只在外层写 WHERE depth ，那只是在结果阶段裁剪。

配置上限时，别把安全阀当业务条件

业务条件负责说明“什么时候应该结束”，服务端上限负责说明“异常时最多允许跑到哪里”。MySQL 8.4 手册列出的 cte_max_recursion_depth 默认值是 1000，作用域为 Global、Session；它超过阈值后终止 CTE，但不能修复一个逻辑上永远为真的 WHERE 条件。

MySQL 递归 CTE 的递归深度、执行时间、LIMIT 与 KILL QUERY 安全边界关系框图 — 图2：MySQL 递归 CTE 的静态保护关系示意，递归成员同时受到深度、时间和行数边界约束。

-- 只限制当前连接，避免把临时排查参数扩散到新会话
SET SESSION cte_max_recursion_depth = 32;
-- 给本次连接中的 SELECT 设置毫秒级超时保护
SET SESSION max_execution_time = 1000;

WITH RECURSIVE seq (n) AS (
    -- 锚点从 1 开始，给 n 一个明确的整数类型
    SELECT 1
    UNION ALL
    -- 递归成员继续增长，但业务条件和 LIMIT 共同限制规模
    SELECT n + 1
    FROM seq
    WHERE n

递归成员里的 LIMIT 是 MySQL 8.0.19 起支持的写法。它限制返回到外层的行数，适合给序列生成或可预估的遍历加硬上限；版本较老时不要照搬。若查询已经失控，可以从另一会话执行 KILL QUERY，但这只是中止手段，仍应回头修递归成员。

报错时沿着三个结果判断

不要看到“超过递归深度”就立刻把全局值调大。先用同一组输入做最小复现，并分别观察下面三类证据：

现象	优先检查	判断
很快撞到深度上限	递归列是否变化、WHERE 是否会变假	多半是条件缺失、方向写反或遇到循环数据
深度不高但执行很慢	递归 JOIN 的输入规模、执行时间	可能每轮扩张过大，需收窄连接条件并保留超时
结果只多一行或少一行	`、与锚点边界`	通常是包含式结束日期、初始层数或外层过滤位置不一致

-- 先看当前会话的保护值，再解释查询结构
SHOW SESSION VARIABLES LIKE 'cte_max_recursion_depth';
EXPLAIN WITH RECURSIVE day_list (dt) AS (
    -- 保留与正式查询一致的锚点，便于比较边界
    SELECT DATE('2026-01-01')
    UNION ALL
    -- 用可证明会收敛的条件生成下一日期
    SELECT dt + INTERVAL 1 DAY FROM day_list
    WHERE dt

EXPLAIN 只能帮助你看计划和递归成员，不能替代对实际边界的判断。若层级数据允许回指父节点，单纯增加深度上限只能把问题延后；应在递归列中携带路径并排除已访问节点，或改用 UNION DISTINCT 消除重复行（前提是去重语义确实符合业务）。