SQL解析器仅做语法展开不优化嵌套子查询，超32层（SQL Server）或31层（MySQL）直接报错；PostgreSQL 5–7层后优化器失效；相关子查询无法重写为JOIN；推荐用CTE、窗口函数和临时表重构。
SQL解析器根本不会尝试“自动扁平化”嵌套子查询——它只做语法展开，不负责语义等价重写。
Parser 层只递归展开，不优化逻辑
当你写 WHERE id IN (SELECT id FROM (SELECT id FROM t))，SQL Server 或 MySQL 的 parser 不会把它变成 JOIN t；它只是按括号层级逐层构建表达式树。一旦总深度 ≥ 32（SQL Server）或 ≥ 31（MySQL），直接报 Msg 319 或 ERROR 1235，连执行计划都不生成。
- 这不是性能问题，是栈空间耗尽或硬编码计数器溢出
- 即使每层子查询只返回 1 行、逻辑极简单，只要结构嵌套超限，就拒绝执行
- PostgreSQL 虽不报错，但 5–7 层后优化器放弃精确估算，执行计划里大量出现
Materialize节点，Actual Rows暴涨
为什么不能靠数据库“猜中你的意图”
优化器对子查询的重写有严苛前提：必须是非相关子查询（uncorrelated）、无聚合、无 GROUP BY、无 ORDER BY、无 TOP、且能静态判定最多返回 1 行。现实中绝大多数业务嵌套都含 WHERE o.user_id = u.id 这类相关引用，一上来就被排除在重写范围外。
-
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)→ 不会转成INNER JOIN，仍走嵌套循环 -
SELECT (SELECT MAX(created_at) FROM logs l WHERE l.user_id = u.id)→ 每行触发一次独立查找，无法合并 - 加
OPTION (QUERYTRACEON 8605)反而禁用重写路径，让本可折叠的常量子查询也原样保留
真正可控的三种重构方式
别等报错才动手——3 层就是警戒线。以下方法按优先级排列，适用于 MySQL 8.0+、PostgreSQL、SQL Server：
- 用
WITH拆分命名中间结果：WITH shipped_orders AS (SELECT order_id, user_id FROM orders WHERE status = 'shipped')，再JOIN。注意：每个 CTE 必须显式列名，禁用SELECT *，否则外层WHERE无法下推 - 相关子查询一律改窗口函数：
AVG(salary) OVER (PARTITION BY dept_id)替代(SELECT AVG(salary) FROM e2 WHERE e2.dept_id = e1.dept_id)；MySQL 8.0+、PostgreSQL、SQL Server 均支持 - 当 CTE 被引用 ≥ 3 次，或含高开销聚合/窗口函数时，强制物化：用
CREATE TEMPORARY TABLE tmp AS SELECT ...，并立刻建索引，避免重复计算
复杂点永远不在语法层面——而在数据边界上。比如 user_recent_products CTE 中用户没下单，LEFT JOIN 后字段全为 NULL，但业务代码没判空，直接参与后续计算，结果错得无声无息。
