必须重构——MySQL在约31层嵌套时解析器栈溢出报错，不可配置；PostgreSQL/SQL Server虽不硬报错但优化器失效，执行计划不可信；CTE非万能，盲目使用反增负担；兜底方案是分步+临时表。

有，必须重构——不是“建议”，是数据库解析器和优化器在三层以上就已开始失控。

MySQL 31层是硬性解析失败点，不是性能临界值

MySQL 解析器在 PREPARE 阶段就用尽 thread_stack，默认 192KB～256KB，一旦嵌套别名套别名、WITH 套 SELECT 套 UNION ALL，栈溢出直接报错：ERROR 1038 (HY001): Out of sort memory 或更隐蔽的 Lost connection to MySQL server during query。你连 EXPLAIN FORMAT=TREE 都看不到，因为执行计划根本没生成。

实测确认：MySQL 5.7 和 8.0 均卡在约 31 层，且该限制不可配置；max_sp_recursion_depth 不影响子查询嵌套层级。

• 别信“我这跑得通所以还能加一层”——数据量涨、版本升级、连接池复用线程栈，都可能突然崩
• SELECT * FROM (SELECT * FROM (SELECT ...)) 这类结构最危险：每层 SELECT * 都阻止谓词下推，外层 WHERE 白加
• 视图嵌套也计入：v1 → v2 → v3 → v4 是 4 层，SQL Server 中直接触发 Msg 319

PostgreSQL/SQL Server 虽不报错，但执行计划已不可信

PostgreSQL 不设硬报错，但嵌套超 5–7 层后，优化器放弃精确代价估算，大量插入 MATERIALIZE 节点，EXPLAIN ANALYZE 显示 Actual Rows 暴涨数个数量级，查询从 0.2 秒变成 200 秒。

SQL Server 在 32 层全局嵌套上限内虽不立即报错，但视图链或 CTE 嵌套超 3 层后，WHERE 基本无法下推到基表，执行计划中频繁出现 Table Spool (Eager Spool) 且占比超 60%，就是优化器已放弃稳定决策的信号。

• 含 GROUP BY、WINDOW 或 LATERAL 的嵌套，退化更快
• ORDER BY + LIMIT 塞进子查询，多数数据库无法下推，反而强制对全量中间结果排序
• 同一查询在不同时间生成完全不同执行计划，说明优化器已失去可预测性

CTE 不是语法糖，而是可控切片工具，但有明确使用边界

CTE 强制逻辑命名、杜绝跳层依赖、支持调试（可单独运行某段），但它不是万能平替。盲目替换会加重负担：

• 只被引用 1 次、无参数、逻辑简单（如单表过滤）时，直接写 JOIN 更高效
• MySQL 8.0.23 之前无 MATERIALIZED 提示，用 CTE 替代本可内联的视图 = 主动放弃优化机会
• CTE 定义里带 ORDER BY 或 LIMIT，MySQL 会意外禁用物化，导致重复计算
• 必须显式声明字段名：SELECT * 在跨版本迁移时极易因列序变化导致字段错位

真正兜底方案：分步 + 临时表，而非硬扛单条SQL

当业务逻辑带状态判断、字段需多次复用、或中间结果参与多个聚合分支时，“一条 SQL 搞定”只会让问题更重。此时应主动放弃声明式幻想，改用数据库可控的原子步骤：

• 第一步只取驱动集：CREATE TEMPORARY TABLE tmp_users AS SELECT id, role FROM users WHERE status = 'active'
• 立刻建索引：CREATE INDEX idx_role ON tmp_users(role)，别等后面 JOIN 时才发现慢
• 避免在视图里反复复用相同聚合逻辑（如 COUNT(*) GROUP BY user_id 出现在 4 层嵌套里）
• 应用层更适合处理分支逻辑：权限控制、字符串拼接、空值转默认值、多条件组合筛选

复杂点在于：三层嵌套往往源于“先筛再聚合再关联”的线性思维，而数据库真正擅长的是基于统计信息做连接顺序决策。你改外层一个 WHERE，可能让内层从索引跳过退化为全表扫描，却看不出哪一层出的问题——这种不可见性，才是最危险的。