必须将聚合计算拆分为两层SQL，因为同一SELECT层级无法复用聚合别名进行HAVING过滤或二次运算；需用CTE或子查询固化中间结果，并注意NULLIF、COALESCE和ROUND等防御性处理。
不能在同一个 SELECT 层级里直接用 SUM(a) 和 SUM(b) 算出百分比再参与下一步逻辑判断——必须拆成两层，否则要么报错，要么结果错。
GROUP BY 后无法复用聚合字段做条件或算术运算
比如想算「毛利率 = (收入 - 成本) / 收入」，写成 SELECT (SUM(revenue) - SUM(cost)) / SUM(revenue) 看似可行，但一旦加 HAVING 或想在外层用这个值做 CASE WHEN 分类，就会出问题。因为 SQL 执行顺序中，HAVING 虽然作用于分组后，但它只能引用原始聚合表达式（如 SUM(revenue)），不能引用你刚起的别名（如 gross_margin）。
-
HAVING SUM(revenue) > 1000✅ 合法 -
HAVING gross_margin > 0.2❌ 报错：列不存在（PostgreSQL）或被忽略（MySQL 5.7+ strict mode） - 同一层
SELECT中写SUM(revenue) / NULLIF(SUM(cost), 0)可行，但若后续还要按这个比率排序或分段统计，就必须把它固化下来
子查询或 CTE 是唯一可靠路径
把第一层聚合结果当作一张临时表，才能安全地二次加工。CTE 更易读，子查询兼容性更好，但都绕不开一个核心动作：命名中间结果。
- 子查询必须带别名，例如
FROM (SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept) AS dept_summary——漏掉AS dept_summary在 MySQL 和 PostgreSQL 都会报错 - CTE 中定义的字段名，外层可直接引用，但不能跨 CTE 引用未声明字段，比如
WITH a AS (...), b AS (SELECT * FROM a WHERE cnt > 5)合法，但b里不能突然引用a没 SELECT 出来的dept_name - 如果要同时算平均值、中位数、Top 3，CTE 比嵌套三层子查询更可控，避免括号错位或字段名重复覆盖
二次计算时最容易漏掉的三个防御点
不是语法错，而是逻辑崩——尤其在线上环境跑着跑着突然 NULL 或除零异常。
-
NULLIF(denominator, 0)必须加：哪怕业务上“应该不会为 0”，数据库不认“应该”，只认执行时值。没它，SUM(revenue) / SUM(cost)遇到成本为 0 的组直接报错 -
COALESCE(..., 0)要看场景：如果某组根本没数据（比如新部门还没人），SUM(salary)返回NULL，后续除法或比较会传播NULL；这时是否补 0，取决于业务语义——是“无数据”还是“0 元” -
ROUND(..., 4)别省：浮点误差在百分比、毛利率这类指标上会放大，比如0.29999999999999993显示成 30% 前必须四舍五入，否则前端展示或下游判断会出偏差
WHERE 和 HAVING 的边界必须卡死
很多人试图在 HAVING 里塞复杂逻辑，比如 HAVING AVG(amount) > (SELECT AVG(amount) FROM orders)，这没问题；但一旦混入明细字段（如 HAVING status = 'paid'）或窗口函数别名（如 HAVING rank_num = 1），就全乱了。
-
WHERE过滤的是原始行，不能用任何聚合函数 -
HAVING过滤的是分组后结果，只能用内层SELECT中出现的聚合表达式或GROUP BY字段 - 二次计算（如“订单数超均值的客户”）必须在外层完成：
HAVING只能筛出“哪些客户订单数达标”，但“这些客户的平均消费”得靠外层AVG()算——不能指望HAVING返回一组值再自动喂给外层聚合
真正麻烦的不是写两层 SQL，而是搞清哪一层该做什么事：内层只负责“把原始数据压成一行一行的聚合结果”，外层才负责“拿这些行当输入，做真正的业务逻辑”。字段别名、NULL 处理、执行顺序——这三个点卡不住，再漂亮的 CTE 也会在线上返回意外结果。
