MySQL嵌套查询默认最多31层，超限会直接报错拒绝执行；SQL Server硬性限制32层；PostgreSQL虽无层数报错但5–7层后性能断崖式下降。
嵌套查询报错，大概率不是你写错了，而是数据库解析器主动拒绝执行——它有硬性层级上限。
MySQL 默认最多嵌套 31 层
MySQL 在解析 SQL 时会维护一个递归调用栈，用于处理子查询嵌套。这个栈深度受 max_sp_recursion_depth 和内部 parser 限制共同约束。虽然文档未明说“子查询层数”，但实测中连续嵌套 SELECT ... WHERE id IN (SELECT ... WHERE id IN (...)) 超过 31 层就会触发 ERROR 1235 (42000): This version of MySQL doesn't yet support 'subquery in subquery' (or similar) 类错误（具体提示因版本而异）。这不是语法不支持，是 parser 主动截断。
- MySQL 5.7/8.0 均默认限制在 31 层左右，不可配置提升
- 报错通常发生在 PREPARE 阶段，甚至还没走到优化器，所以
EXPLAIN都看不到 - 哪怕每层只返回 1 行、逻辑极简单，只要嵌套结构超过阈值，就直接拒掉
SQL Server 硬性限制为 32 层
SQL Server 明确声明：视图、存储过程、函数、触发器或任意组合的嵌套总深度不能超过 32。一旦触达，必定报 Msg 319, Level 15, State 1: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
- 这个计数是全局的：A 视图引用 B，B 引用 C，C 引用 D……到第 33 层就崩
- CTE 的递归部分（
WITH RECURSIVE）单独计算，不计入此 32 层，但非递归 CTE 的嵌套仍算 -
sp_depends已弃用，查依赖链必须靠sys.dm_exec_describe_first_result_set或手动解析OBJECT_DEFINITION
PostgreSQL 没有固定层数报错，但会悄悄退化
PostgreSQL 不设硬性嵌套层数限制，但它会在解析阶段对深层嵌套做“语义折叠”。一旦嵌套超过约 5–7 层，优化器就可能放弃精确代价估算，转而选择全表扫描或强制物化中间结果，导致性能断崖式下跌——你不会看到报错，只会发现查询从 0.2 秒变成 200 秒，且 EXPLAIN ANALYZE 显示大量 Materialize 节点和 Actual Rows 暴涨。
- 没有
ERROR不代表安全；它只是把失败藏在慢和内存溢出里 - 嵌套中若含
GROUP BY、WINDOW或LATERAL，退化更快 - 用
WITH替代嵌套后，如果没加MATERIALIZED，PG 可能仍当内联子查询重算多次
别等报错才行动，3 层就是警戒线
所有主流数据库在 3 层嵌套以上就开始失去稳定行为：MySQL 可能还撑得住，SQL Server 的依赖管理已混乱，PostgreSQL 的执行计划已不可信。真正危险的不是“第 32 层崩了”，而是“第 4 层起，你再也无法预测它怎么跑”。拆分动作要前置——只要看到 WHERE x IN (SELECT ... WHERE y IN (SELECT ...)) 这类模式，就该立刻考虑 WITH 或临时表。
