多级嵌套子查询应避免，优先用with cte摊平逻辑；where中不能引用group by子查询字段，需改用having或join；禁止嵌套聚合，须分层计算；三层以上嵌套必须用cte提升可读性与性能。
多级嵌套子查询不是不能用，而是绝大多数时候不该用——它会让逻辑耦合、调试困难、性能不可控，且一旦出错（比如Unknown column或Invalid use of group function），排查路径极长。真正该做的是用WITH把嵌套“摊平”，让每一步可命名、可复用、可单独验证。
为什么WHERE里写GROUP BY子查询会报错
常见错误现象是：在WHERE中直接引用含GROUP BY的子查询字段，MySQL 报 Unknown column 'xxx' in 'where clause'，SQL Server 或 PostgreSQL 也拒绝解析。这不是语法写错了，是作用域根本没打通——外层WHERE看不到内层分组后的列。
- 子查询结果必须显式命名字段（如
SUM(amount) AS total），且外层只能引用这些别名 - 想过滤聚合结果？改用
HAVING（在GROUP BY之后）或提前用JOIN把聚合值拉出来 - 不要写
WHERE sales > (SELECT AVG(sales) FROM t GROUP BY dept)——这语义不合法；应先算出dept_avg，再JOIN或用CTE
MAX(AVG(x))这类嵌套聚合为什么总失败
所有主流数据库（MySQL/PostgreSQL/SQL Server/Oracle）都会拒绝执行SELECT MAX(AVG(price)) FROM sales GROUP BY region，报错类似aggregate function calls cannot be nested。根源在于SQL执行顺序：GROUP BY → 各组内聚合 → 外层聚合，中间结果是行集，不是可被二次聚合的列值流。
- 正确做法是用子查询或CTE分两层：内层按
region算AVG(price)，外层对这个结果集再MAX() - 窗口函数（如
AVG(price) OVER (PARTITION BY region)）不解决这个问题，它只是重定义计算范围，不改变分组层级 - 别指望优化器自动“理解意图”——它只认执行计划，而嵌套聚合没有合法计划
三层以上嵌套时，CTE比子查询更可靠
当嵌套达到三层（比如SELECT ... FROM (SELECT ... FROM (SELECT ... FROM t) a) b），可读性断崖下跌，且MySQL 5.7/8.0容易触发Using temporary; Using filesort，执行时间从毫秒跳到秒级。CTE不是语法糖，它是重构信号：告诉自己和同事——这段逻辑需要分步表达。
- 同一中间结果被多次引用（如用户首单时间既用于
JOIN又用于WHERE），必须提成CTE，否则重复执行+索引失效 - 过滤条件重复（如
dt='20231001'在多个子查询里出现三次），用CTE统一收口，改一处全生效 - CTE不强制物化，性能通常与等价子查询一致，但优化器更可能识别复用机会（尤其SQL Server和MaxCompute）
什么时候还非得用嵌套子查询
极少数场景下，子查询仍是合理选择：标量子查询用于SELECT列表补字段（如(SELECT name FROM users WHERE id = o.user_id)），或相关子查询用于存在性判断（如WHERE EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id AND l.status = 'shipped')）。但注意：
- 标量子查询返回空时结果为
NULL，若参与比较（如amount > (subquery)），整个条件变成UNKNOWN，建议包一层COALESCE((subquery), 0) - 相关子查询在大表上性能敏感，优先考虑
LEFT JOIN + GROUP BY替代 - 如果子查询里开始出现
ORDER BY或LIMIT，基本说明设计已偏离正轨——这类操作在多数数据库中不被允许嵌套，应拆到CTE或临时表
真正难的不是写出能跑的SQL，而是写出别人（包括两周后的你自己）能快速看懂、安全修改的SQL。嵌套子查询像手写汇编，CTE才是带注释的高级语言——别等到报表改不动了才想起重构。
