CTE 递归查询深度过大导致栈溢出的 max_recursion 设置-SQL-PHP中文网

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

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

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

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

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

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

word报告自动生成神器

Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。

下载

容易踩的坑：

提示必须放在语句末尾，紧贴 ; 前，写在 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 更可靠

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