必须重构——MySQL 31层硬性报错，SQL Server 32层必崩，PostgreSQL 5层后执行计划不可信；解析器栈溢出或优化器失效导致查询无法执行或结果不可靠。
因为五层以上嵌套子查询在主流数据库中已超出解析器或优化器的实际承载能力——MySQL 31 层就硬性报错，SQL Server 32 层必崩，PostgreSQL 5 层后执行计划已不可信，不是“不推荐”，而是“根本跑不通”或“结果不可靠”。
MySQL 在 PREPARE 阶段直接拒绝执行
超过 31 层嵌套的 SELECT 语句，MySQL 解析器会在语法解析阶段就中断，连 EXPLAIN 都无法运行。这不是配置问题，max_sp_recursion_depth 对此无效，thread_stack 默认值（192KB～256KB）也撑不住深层递归调用栈。
- 典型错误：
ERROR 1235 (42000): This version of MySQL doesn't yet support 'subquery in subquery' - 哪怕每层只返回 1 行、不含 JOIN 或 GROUP BY，只要括号嵌套达 32 层，SQL 就被 parser 主动截断
- ORM（如 Django ORM、MyBatis）或低代码平台自动生成的 wrapper 可能悄悄加 2～3 层，你写的 3 层实际变成 5 层，上线即失败
PostgreSQL 不报错但执行计划彻底失控
PostgreSQL 不设硬性层数限制，但优化器在约 5～7 层后会放弃精确代价估算，转而插入大量 MATERIALIZE 节点，并频繁触发全表扫描。你不会看到错误，只会发现同一 SQL 在不同时间生成完全不同的执行计划，且 EXPLAIN ANALYZE 中 Actual Rows 暴涨几个数量级。
- 含
GROUP BY、LATERAL或未加MATERIALIZED的WITH子句，退化更快 -
ORDER BY或LIMIT出现在内层时，外层WHERE条件基本无法下推到基表 - 字段别名作用域模糊、
NULL传播路径断裂，导致逻辑错乱却无提示
SQL Server 全局嵌套深度计入视图/函数/触发器链
SQL Server 明确将视图、存储过程、函数、触发器的调用层级合并计数，上限为 32 层。哪怕你只写纯 SELECT ... WHERE id IN (SELECT ...)，只要嵌套结构达到第 33 层，必定触发 Msg 319, Level 15, State 1。
- 错误信息：
Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32) -
MAXRECURSION只对WITH RECURSIVE生效，对普通嵌套子查询完全无效 - 视图 A → 视图 B → 视图 C → 子查询 D → 子查询 E，到第 33 层就崩，和是否递归无关
- 执行计划中
Table Spool (Eager Spool)占比超 60%，就是嵌套过深的静默信号
三层就是真实警戒线，重构不是为了“好看”
所谓“禁止五层以上”，本质是承认数据库底层能力边界：解析器栈深、优化器估算精度、执行时内存分配都存在物理上限。CTE、临时表、分步处理不是妥协方案，而是让 SQL 能通过 PREPARE、生成稳定执行计划、返回可信结果的必要手段。
- CTE 必须显式声明字段名，禁用
SELECT *，否则跨版本迁移易因列序变化导致错位 - 中间结果被引用 ≥2 次，或含高开销聚合/窗口函数时，优先建
TEMPORARY TABLE并加索引 - 触发器里嵌套子查询更危险——MySQL 直接报
ERROR 1093或1442，PostgreSQL/SQL Server 则静默变慢数十倍
真正难处理的不是“怎么写五层嵌套”，而是当它在测试环境跑通、上线后某天突然报错或变慢十倍时，你得从几百行 SQL 里定位哪一层触发了数据库的隐性熔断阈值——这种调试成本远高于一开始就拆成线性逻辑。
