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 更可靠
栈溢出往往暴露的是数据异常或逻辑缺陷，而不是参数没调够。
