子查询在WHERE中引用GROUP BY字段会报错，因作用域不穿透；应改用JOIN预计算聚合值或HAVING过滤；聚合函数套子查询易致NULL失效，建议COALESCE处理；多层嵌套性能差，宜用临时表、CTE或窗口函数替代。
子查询在WHERE中用GROUP BY字段会报错
直接在 WHERE 子句里写带 GROUP BY 的子查询，MySQL 会报 Unknown column 'xxx' in 'where clause'——因为子查询的聚合结果不能被外层 WHERE 直接引用（作用域不穿透）。常见于想“查销售额超过部门平均值的员工”这类逻辑。
正确做法是把聚合结果提前算好，再 JOIN 或用 HAVING 过滤：
- 用
JOIN关联子查询：把部门平均销售额作为临时表，和主表ON匹配 - 改用
HAVING：把条件移到分组后，比如先GROUP BY emp_id，再HAVING SUM(amount) > (SELECT AVG(total) FROM (...)) - 避免在
WHERE中嵌套含GROUP BY或ORDER BY的子查询，除非明确支持相关子查询（如 PostgreSQL 的 LATERAL）
聚合函数套子查询导致NULL值意外丢失
SUM()、COUNT() 等聚合函数遇到空集默认返回 NULL，但若外层再套一层子查询（比如 (SELECT SUM(sales) FROM orders WHERE ...)），而该子查询没数据，整个表达式就变成 NULL，可能让 WHERE col > (subquery) 判断失效（因为 NULL > 100 是 UNKNOWN，不为 TRUE）。
实操建议：
- 给子查询加
COALESCE：写成COALESCE((SELECT SUM(sales) ...), 0) - 确认业务是否允许“无数据=0”，有些场景（如未发生采购）应保留 NULL 更准确，那就得改用
LEFT JOIN+ 聚合，而非标量子查询 - 注意
COUNT(*)和COUNT(col)差异：前者对空集返回 0，后者也返回 0，但若子查询本身没行，整个标量子查询仍是 NULL
多层嵌套子查询性能断崖式下降
三层以上子查询（尤其每层都含 JOIN 或 GROUP BY）在 MySQL 5.7/8.0 中容易触发临时表+文件排序，执行时间从毫秒跳到秒级。典型表现是 EXPLAIN 显示 type=ALL 或 Extra: Using temporary; Using filesort。
优化方向：
- 把最内层子查询拆成临时表（
CREATE TEMPORARY TABLE tmp AS SELECT ...），加索引后再 JOIN - 用 CTE 替代嵌套（MySQL 8.0+）：可读性提升，优化器也更可能复用中间结果
- 检查是否真需要嵌套——很多报表需求其实用一次
JOIN+GROUP BY+ 条件聚合（如SUM(CASE WHEN ...)）就能替代两层子查询
窗口函数比嵌套子查询更安全高效
想查“每个订单的金额占客户总消费比例”，用子查询要写成 amount / (SELECT SUM(amount) FROM orders o2 WHERE o2.cust_id = o1.cust_id)，这是相关子查询，N×M 复杂度；而 SUM(amount) OVER (PARTITION BY cust_id) 一行搞定，且结果确定、不依赖执行顺序。
适用前提：
- 数据库支持窗口函数（MySQL 8.0+、PostgreSQL、SQL Server 2012+）
- 避免在窗口函数中混用
ORDER BY和非确定性函数（如NOW()），否则可能导致结果每次执行不一致 - 注意
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW和RANGE的语义差异，时间维度聚合优先用ROWS
复杂报表里，能用窗口函数的地方尽量别硬套子查询——不是所有团队都记得给子查询加索引，但窗口函数天然走执行计划优化路径。
