必须重构——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，可能让内层从索引跳过退化为全表扫描，却看不出哪一层出的问题——这种不可见性，才是最危险的。
