GROUP BY后不能在同层SELECT或HAVING中直接复用聚合结果做二次计算，需用子查询或CTE先聚合再运算，并注意NULLIF防除零、COALESCE处理空值、ROUND控制精度及WHERE/HAVING分工。
GROUP BY 后不能直接用聚合字段做算术运算
写 SELECT SUM(a) * 2 FROM t GROUP BY b 没问题，但一旦想在 HAVING 或同一层 SELECT 里复用这个 SUM(a) 做除法、百分比、差值，就会报错或逻辑错——因为 SQL 执行顺序中，SELECT 列的表达式是在 GROUP BY 和聚合之后计算的，但你不能在同一个层级“引用”聚合结果再参与新计算（除非重写表达式）。
常见错误现象：column "sum(a)" does not exist（PostgreSQL）、Invalid use of group function（MySQL），或者 MySQL 允许但结果不符合预期（比如把聚合前的原始值参与了运算）。
- 别在
SELECT里写SUM(a) / SUM(b)然后幻想它能自动按组对齐——它确实能，但前提是a和b都是同组内可聚合的数值，不是混着明细和聚合乱用 - 如果要算“每组销售额占总销售额的百分比”，
SUM(sales)是组内值，SUM(sales) OVER()才是全表总和——这是窗口函数的活，不是GROUP BY自己能扛的 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，会拒绝那些 SELECT 列里出现非聚合、非 GROUP BY 字段的语句，容易误以为是算术问题，其实是语义不合法
用子查询或 CTE 拆开聚合与二次计算
最稳的方式：先 GROUP BY 出基础聚合结果，再套一层查询做算术。CTE 更易读，子查询更通用。
例如算各品类「毛利率 = (收入 - 成本) / 收入」：
WITH agg AS (
SELECT category,
SUM(revenue) AS total_rev,
SUM(cost) AS total_cost
FROM orders
GROUP BY category
)
SELECT category,
ROUND((total_rev - total_cost) / NULLIF(total_rev, 0), 4) AS gross_margin
FROM agg;NULLIF(total_rev, 0) 是关键：避免除零错误，返回 NULL 而不是报错。别漏掉它，尤其当某组 revenue 可能为 0 时。
- 子查询写法也等价，但嵌套深了容易括号错位，CTE 在复杂场景更可控
- 注意字段别名要在子查询/CTE 里定义好，外层才能引用；别在外部 SELECT 里重复写
SUM(revenue) - SUM(cost)，那会重新聚合，结果错 - 如果二次计算涉及排序或限制（比如取 Top 3），必须在外层加
ORDER BY和LIMIT，GROUP BY 内部不保证顺序
WHERE 和 HAVING 的分工必须清楚
WHERE 过滤的是聚合前的行，HAVING 过滤的是聚合后的组。想筛“毛利率 > 30% 的品类”，必须用 HAVING，且得基于聚合字段写条件。
错误写法：HAVING (SUM(revenue) - SUM(cost)) / SUM(revenue) > 0.3 —— 看似对，但没处理分母为 0，运行时可能报错。
- 正确写法：
HAVING SUM(revenue) > 0 AND (SUM(revenue) - SUM(cost)) / SUM(revenue) > 0.3 - 别在
HAVING里用别名（如HAVING gross_margin > 0.3），绝大多数数据库不支持——别名只在 SELECT 输出阶段生效，HAVING 执行时还不可见 - 如果过滤条件同时含明细逻辑（如“用户注册时间 > '2023-01-01'”）和聚合逻辑（如“订单数 > 5”），WHERE 放前者，HAVING 放后者，顺序不能颠倒
除零、NULL 和浮点精度是高频翻车点
聚合后做除法，三个坑几乎必遇：被除数为 0、分子或分母为 NULL、小数位数失控。它们不会报语法错，但结果会静默异常。
- 永远用
NULLIF(denominator, 0)替代裸除，MySQL/PostgreSQL/SQL Server 都支持 -
SUM()遇到全 NULL 列会返回NULL，不是 0；如果希望空组返回 0，得套COALESCE(SUM(x), 0) - 百分比建议统一用
ROUND(expr, 4)控制小数位，避免DECIMAL和FLOAT类型混用导致精度漂移（比如0.1 + 0.2 != 0.3）
这些细节不显眼，但上线后查数据对不上，八成卡在这儿。
