三层是数据库解析器和优化器共同失效的临界点，超三层即触发MySQL栈溢出报错、PostgreSQL执行计划崩坏、SQL Server全局嵌套超限，必须重构而非优化。
三层是数据库解析器和优化器共同失效的临界点，不是风格建议，而是硬性工程边界——超了就报错、变慢或返回错结果。
MySQL在31层直接拒绝解析，但3层就该动手重构
MySQL解析器用递归栈展开子查询语法树，thread_stack默认仅192KB～256KB。实测中，含JOIN、GROUP BY和LIMIT的嵌套到第5层就可能栈溢出，报ERROR 1038 (HY001): Out of sort memory；到31层必报ERROR 1235 (42000): This version of MySQL doesn't yet support 'subquery in subquery'。这不是语法不支持，是parser主动截断，连EXPLAIN都看不到。
-
max_sp_recursion_depth对子查询嵌套完全无效，无法通过配置绕过 - ORM（如Entity Framework）或SSMS查询设计器可能悄悄加wrapper，把你的3层变成5层
- 超过3层后，字段别名作用域混乱，
Unknown column错误频发，且难以定位在哪一层出的问题
PostgreSQL不报错，但5层后执行计划已不可信
PostgreSQL允许任意层数语法通过，但优化器在5–7层后放弃精确代价估算，转而插入大量MATERIALIZE节点，频繁触发全表扫描。你不会看到错误，只会发现EXPLAIN ANALYZE中Actual Rows暴涨数个数量级，查询从0.2秒变成200秒。
- 含
GROUP BY、LATERAL或未加MATERIALIZED提示的WITH，退化更快 -
ORDER BY或LIMIT一旦出现在内层，外层WHERE基本无法下推到基表，索引形同虚设 -
sys.dm_exec_describe_first_result_set在≥4层后开始丢失列来源信息，审计和调试失能
SQL Server的32层是全局调用栈硬限制
SQL Server明确声明：视图、函数、存储过程、触发器任意组合的嵌套总深度不能超过32层。第33层必报Msg 319, Level 15, State 1: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。这个计数是全局的，v1 → v2 → v3 → v4到第33层就崩，和是否递归无关。
-
MAXRECURSION只对WITH RECURSIVE生效，对普通嵌套子查询完全无效 - 视图嵌套超3层后，谓词基本无法下推，外层
WHERE很可能只作用于最终结果，而非基表 - 执行计划中频繁出现
Table Spool (Eager Spool)且占比超60%，就是典型信号
三层以上必须重构，CTE不是万能解药
用WITH替代嵌套子查询确实更可控，但它不是语法糖——CTE强制逻辑切片命名、杜绝跳层依赖、支持条件下推，且便于单独调试。但盲目替换反而有害：
- 被引用＜2次、无参数、逻辑简单的子查询，直接写
JOIN更高效 - CTE中必须显式声明字段名，
SELECT *跨版本迁移时极易因列序变化导致字段错位 - 被引用≥3次或含高开销窗口函数时，应改用临时表并加索引，否则仍反复物化
真正要盯住的不是“层数”本身，而是中间结果是否被重复计算。三层警戒线背后，是数据库对可预测性、可观测性和可维护性的底线要求——一旦越过，你就失去了对执行路径的掌控力。
