MySQL 8.0+ 需通过 SET SESSION 或 SET GLOBAL 设置 cte_max_recursion_depth（如500）来提升递归深度，但不可设为0；该参数仅防超深递归报错，无法解决数据环问题，必须配合路径检测（如JSON或数组记录已访问ID）才能真正防卡死。

MySQL 8.0+ 怎么设 cte_max_recursion_depth 防卡死？

MySQL 默认只允许递归 100 层，超限直接报错 ERROR 3636，而不是挂住——这是保护机制。必须显式调高才能查更深的树。

• 会话级临时改（推荐调试用）：SET SESSION cte_max_recursion_depth = 500;
• 全局改（需 SUPER 权限，重启失效）：SET GLOBAL cte_max_recursion_depth = 500;，还得写进 my.cnf 的 [mysqld] 段才持久
• 不能设为 0：MySQL 不支持“无限制”，设了会报错

注意：这只是兜底，不是解药。如果数据本身有环（比如 A→B→C→A），加到 500 层也照样死在第 3 层，只是报错晚一点。

PostgreSQL 为什么必须用 ARRAY 而不是字符串拼接防环？

PG 没有深度硬限制，全靠逻辑防环。常见错误是用 ',' || id || ',' 做路径判断，结果 id = 1 和 id = 11 在逗号分隔下会误判成重复。

• 锚点里初始化路径：ARRAY[id] AS path
• 递归里追加：r.path || t.id
• WHERE 过滤环：WHERE t.id != ALL(r.path)
• 别用 NOT t.id = ANY(r.path) ——语义等价但可读性差，容易漏括号

ARRAY 类型天然支持成员级精确匹配，性能也比字符串 LIKE 或正则快得多。

SQL Server 的 OPTION (MAXRECURSION n) 为什么总不生效？

这个提示只对紧贴其前的最终 SELECT 生效，位置错、嵌套深、封装层级多都会让它失效。

• 必须放在 SELECT 语句末尾，不能插在 UNION ALL 中间或 CTE 定义里
• CTE 封装进视图或内联表值函数（ITVF）时，OPTION 无法穿透，得挪到外层查询上
• MAXRECURSION 0 是危险操作：一旦有环，可能耗尽内存或触发查询超时，生产环境禁止
• 存储过程中动态根节点，别拼 SQL 字符串，用参数驱动锚查询：WHERE id = @rootId

更稳妥的做法是把 @maxRecursion 设为输入参数，由调用方按实际树深控制。

所有数据库都该用 CYCLE 子句，但不是所有都支持

CYCLE 是 SQL 标准里最干净的防环方案：自动维护路径、标记 is_cycle、默认剪枝。但它只在 PostgreSQL、Oracle、SQL Server 2022+ 原生支持；MySQL 目前不支持。

• PostgreSQL 写法：CYCLE id SET is_cycle TO TRUE DEFAULT FALSE USING path
• SQL Server 2022+ 可用，但旧版本只能手写 path 数组 + != ALL()
• MySQL 用户得自己模拟：加 path_ids 字段存 JSON 或逗号串，并在递归 WHERE 中过滤

真正容易被忽略的是：深度限制和路径检测必须一起用。光调高 cte_max_recursion_depth 或只加 OPTION (MAXRECURSION)，解决不了数据环问题——上线前务必用自连接查显式环，再加应用层插入校验。