超过三层的嵌套子查询不是“写不出来”，而是数据库在解析、优化和执行时大概率会失控——轻则变慢几倍，重则直接报错或返回错误结果。
MySQL 31 层就硬性报错，连 EXPLAIN 都看不到
MySQL 解析器对子查询嵌套有明确栈深度限制，实测超过 31 层会直接触发 ERROR 1235 类错误，比如 This version of MySQL doesn't yet support 'subquery in subquery'。这不是语法不支持，是 parser 主动截断。它发生在 PREPARE 阶段，甚至还没走到优化器，所以你连 EXPLAIN 都无法运行。更关键的是：这个限制不可配置，max_sp_recursion_depth 不影响子查询嵌套层级。
- 哪怕每层只返回 1 行、逻辑极简单，只要结构上嵌套超限，SQL 就被拒掉
- MySQL 5.7 和 8.0 均默认卡在 31 层左右，不是“建议值”，是硬边界
- 别依赖“我这没报错所以还能加一层”——数据量一涨、版本一升级，就崩
PostgreSQL 不报错，但 5 层后执行计划已不可信
PostgreSQL 虽不设硬性层数报错，但嵌套超 5–7 层后，优化器会悄悄放弃精确代价估算，转而生成大量 Materialize 节点，并频繁触发全表扫描。你不会看到错误，只会发现查询从 0.2 秒变成 200 秒，且 EXPLAIN ANALYZE 显示 Actual Rows 暴涨数个数量级。
- 含
GROUP BY、WINDOW或LATERAL的嵌套，退化更快 -
WITH子句若没加MATERIALIZED（PG 12+），仍可能被当作内联子查询反复执行 - 嵌套中一旦出现
ORDER BY或LIMIT，谓词下推基本失效
SQL Server 32 层是全局嵌套上限，视图链也计入
SQL Server 明确规定：存储过程、函数、触发器、视图任意组合的嵌套总深度不能超过 32。一旦触达，必报 Msg 319, Level 15, State 1: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。注意：这个计数是全局的，v1 → v2 → v3 → v4 到第 33 层就崩；而 WITH RECURSIVE 的递归部分单独计算，但非递归 CTE 的嵌套仍算在内。
- 视图嵌套超 3 层后，谓词基本无法下推，外层
WHERE很可能只作用于最终结果，而非基表 - 执行计划中频繁出现
Table Spool (Eager Spool)且占比超 60%，就是典型信号 - 同一查询在不同时间生成完全不同的执行计划，说明优化器已放弃稳定决策
所有数据库在三层以上就开始语义失控
三层嵌套往往源于“先筛再聚合再关联”的线性思维，但数据库更适合用 JOIN 或 CTE 拆解逻辑。一旦嵌套过深，字段别名、NULL 传播、条件下推都变得不可控——你改外层一个 WHERE，可能让内层从索引跳过退化为全表扫描，却看不出哪一层出的问题。
-
WHERE id IN (SELECT ...)这类写法，在数据量稍大时极易让优化器放弃使用索引 - 相关子查询（
DEPENDENT SUBQUERY）在三层以上时，可能对外层每一行重复执行内层逻辑，导致O(n×m×k)级性能恶化 - 真正难调试的不是“为什么慢”，而是“为什么有时候快有时候慢”——执行计划漂移比性能差更致命
三层是警戒线，不是安全线。别等报错或慢查询告警才行动，重构时机就在第一眼觉得“这层嵌套有点绕”的时候。
