一张图看清不同数据库对视图嵌套深度和递归CTE的处理差异。
先摆一个残酷的现实：如果你的SQL Server视图嵌套超过32层，编译器会直接甩给你一个Msg 319报错，连执行计划都生成不了。这可不是什么可配置的软限制，而是解析器调用栈的硬上限，发生在编译阶段。换句话说，根本没得商量。
这时你可能会想到 sp_configure 'nested triggers' 或者跟踪标志 -T2510。可惜，这俩都是烟幕弹——nested triggers 管的是触发器能否递归触发，跟视图嵌套八竿子打不着；-T2510 只影响存储过程，对视图无效。想通过改参数来绕过32层限制？路已经被堵死了。
还有几个容易被忽视的陷阱：
- 视图 A → 视图 B → 视图 C 这种链式引用，每一层都算一次嵌套。32层是全局计数，包含所有对象类型，也就是说存储过程里调视图也会累加。
- SSMS 的查询设计器，或者某些ORM（比如EF的原始SQL封装），会悄悄往你的查询里加 wrapper。本来只有3层的嵌套，被它一包装可能变成5层。所以实际的安全上限远低于32，千万别去试探边界。
那么MySQL这边是什么情况？MySQL的视图本身不支持递归定义——你没法在视图里写 WITH RECURSIVE。所以严格来说，MySQL不存在“视图递归深度”这个概念。但递归CTE是有的，它受 cte_max_recursion_depth 这个系统变量控制，默认值是100。超过这个值会报 Error 3636。
调整方式也比较灵活：
- 想临时生效，用
SET SESSION cte_max_recursion_depth = 500; - 要全局生效（需要SUPER权限），用
SET GLOBAL cte_max_recursion_depth = 500;，但重启会丢失，得写进my.cnf的[mysqld]段才能持久化 - 一个关键限制：不能设为0（即无限制），否则语法错误
- 也别把值设得太高——如果数据本身存在环（比如 A→B→C→A），调高只是让报错来得更慢，根本问题并没有解决
PostgreSQL和Oracle就潇洒多了，它们对视图嵌套深度没有硬性限制。但递归CTE的控制手段差异很大。它们不提供类似SQL Server的 MAXRECURSION 提示，也没有MySQL那样的系统变量可调。一切深度控制，都得靠代码逻辑。
几个实操要点：
- PostgreSQL 必须手动加
depth列，并在递归分支里写WHERE depth < 100。更实用的兜底手段是设置statement_timeout，防止长时间跑飞 - Oracle 的
CONNECT BY必须带NOCYCLE，否则遇到环直接报ORA-01436。同时用LEVEL < 100来控制深度 - 两个数据库都不支持
MAX_RECURSION_DEPTH这类参数——这是SQL Server的专属语法，拿到PG或Oracle里用，会直接报语法错误 - 路径检测比深度控制更重要：PostgreSQL 推荐用
ARRAY+!= ALL(path)来检测环，Oracle 则用CONNECT_BY_ISCYCLE
说了这么多，真正该做的是什么事？依赖数据库配置来调高深度限制，本质上只是掩耳盗铃。视图嵌套过深，往往暴露的是设计问题：比如把多层业务逻辑全塞进视图、缺乏中间表抽象、或者根本没有拆分复杂计算。
更可靠的方案集中在重构与防护上：
- 把深层嵌套的视图拆成多个简单的视图，然后在应用层或存储过程里组合结果
- 用临时表或CTE来替代多层视图引用，这样能避免嵌套计数累积
- 处理树形结构时，优先用CTE + 路径数组（比如
ARRAY[id]或JSON_ARRAY_APPEND），而不是一层层JOIN视图 - 上线前跑一遍
SELECT 1 FROM t t1 JOIN t t2 ON t1.id = t2.parent_id AND t2.id = t1.parent_id，把显式环查出来
记住：深度限制只是最后一道闸门，而环检测和层级预检才是防止爆栈的真正防线。这两个活儿，数据库不会替你干。
