CTE 递归查询深度过大导致栈溢出的 max_recursion 设置

mysql中控制递归CTE深度的是cte_max_recursion_depth（非max_recursive_depth），8.0.3+才支持；postgresql无内置深度限制，需在WITH RECURSIVE中手动添加depth计数和WHERE截断。

MySQL 中 max_recursive_depth 不起作用？先确认版本和变量名

MySQL 8.0.3 之前根本没有递归 CTE 的支持，更不存在该限制参数。8.0.3+ 引入递归 CTE 后，控制深度的是系统变量 cte_max_recursion_depth（注意不是 max_recursive_depth），默认值为 1000。它是个会话级变量，全局设置需用 SET GLOBAL cte_max_recursion_depth = N，但必须有 SYSTEM_VARIABLES_ADMIN 权限。

常见错误是拼错变量名，或在低版本 MySQL 中尝试设置——此时命令会直接报错 Unknown system variable。

• 检查当前值：select @@cte_max_recursion_depth;
• 临时提高（当前会话）：SET cte_max_recursion_depth = 5000;
• 确认是否生效：执行递归查询前，务必再查一次 @@cte_max_recursion_depth，避免被其他 SET 覆盖

PostgreSQL 怎么限制递归深度？没有内置 max_recursion

PostgreSQL 的递归 CTE（WITH RECURSIVE）本身不提供类似 MySQL 的硬性深度开关。栈溢出通常表现为 Error: stack depth limit exceeded，根源是递归分支失控或未设终止条件。

真正可行的控制方式是主动引入深度计数列 + WHERE 截断：

WITH RECURSIVE t AS (   SELECT id, parent_id, 1 AS depth   FROM tree WHERE id = 1   union ALL   SELECT c.id, c.parent_id, t.depth + 1   FROM tree c   JOIN t ON c.parent_id = t.id   WHERE t.depth < 100  -- 关键：显式限制 ) SELECT * FROM t;

• 必须把 depth 列放进递归成员的 SELECT 和 JOIN 条件中
• WHERE t.depth 必须写在递归部分（UNION ALL 右侧），不能只放在最外层 SELECT
• 否则优化器可能延迟过滤，仍触发栈溢出

SQL Server 的 MAXRECURSION 提示怎么用才安全

SQL Server 使用查询提示 OPTION (MAXRECURSION N) 控制深度，0 表示无限制（危险！），默认是 100。但它只影响单条语句，且优先级高于服务器配置。

容易踩的坑：

• 提示必须放在语句末尾，紧贴 ; 前，写在 CTE 定义里或中间都会报错 Incorrect syntax near the keyword 'OPTION'
• 若递归实际路径远超设定值（比如误写成自环），SQL Server 会在第 N+1 层抛出 Msg 530, Level 16, State 1: The statement terminated. The maximum recursion 100 has been exhausted before statement completion.
• 不要依赖 MAXRECURSION 0 处理未知深度数据——一旦逻辑出错，直接耗尽内存或长时间阻塞

跨数据库通用建议：别只靠 max_recursion 挡问题

所有数据库的“深度限制”本质都是兜底机制，不是设计手段。真正健壮的递归查询必须自带业务层面的终止逻辑。

• 检查递归 JOIN 条件是否可能产生自引用（如 parent_id = id）或循环引用（A→B→C→A）
• 对树形结构，加 path 字符串或 Array 记录已访问节点，在递归成员中用 @path NOT LIKE '%/id/%' 或 NOT id = ANY(path) 排除重复
• 在应用层预估最大合理深度（例如组织架构一般不超过 12 层），把这个数字作为 WHERE depth 的依据，比盲目调高 limit 更可靠

栈溢出往往暴露的是数据异常或逻辑缺陷，而不是参数没调够。