HAVING是专用于分组后筛选聚合结果的子句，必须紧随GROUP BY之后；WHERE在分组前执行，不可用聚合函数，否则报错；HAVING仅能引用分组字段、聚合函数或部分数据库支持的SELECT别名，不可用未分组非聚合列。
分组后想对聚合结果再筛一次，HAVING 是最直接的解法，但用错位置、用错字段、跨组逻辑一来就崩——这不是语法不会，是执行顺序和语义边界没卡准。
为什么 WHERE 里写 COUNT(*) > 5 一定报错？
WHERE 在分组前执行，此时 COUNT(*) 还没算出来，数据库连“有多少行属于同一组”都不知道。常见错误信息：Invalid use of group function（MySQL）或 column "count" does not exist（PostgreSQL）。
- 正确做法：先
GROUP BY，再用HAVING COUNT(*) > 5 - 错误写法示例：
SELECT user_id, COUNT(*) FROM orders WHERE COUNT(*) > 5 GROUP BY user_id→ 直接语法拒绝 - 如果只想筛时间范围，必须放
WHERE：比如WHERE order_date >= '2024-01-01'，否则全表先分组再丢弃，浪费资源
HAVING 能用哪些字段？哪些一用就炸？
HAVING 只认三类东西：分组字段本身、聚合函数、SELECT 中定义的别名（注意兼容性）。其他一律不认。
- ✅ 安全可用：
HAVING dept = 'sales'（dept在GROUP BY中）、HAVING AVG(salary) > 8000、HAVING avg_sal > 8000（MySQL 5.7+ / PostgreSQL 支持别名） - ❌ 立刻报错：
HAVING status = 'active'（status没进GROUP BY也没被聚合）、HAVING created_at > '2024-01-01'（原始时间字段未分组） - ⚠️ 兼容性坑：SQLite 和老版 MySQL 不支持
HAVING引用别名，得写成HAVING AVG(salary) > 8000而非HAVING avg_sal > 8000
什么时候 HAVING 彻底不够用，必须上子查询或 CTE？
HAVING 只能判断“本组是否达标”，一旦要拿本组和别组比、或做否定判断、或复用聚合结果二次计算，它就失效了。
- 需要跨组比较：比如“销售额高于所有部门平均值的部门” → 必须用子查询先算出全局均值：
HAVING SUM(amount) > (SELECT AVG(total) FROM (SELECT SUM(amount) AS total FROM sales GROUP BY dept) t) - 需要否定逻辑：比如“买过 A 商品但从未买过 B 商品的用户” → 得靠
NOT EXISTS或LEFT JOIN ... IS NULL，HAVING写不出“从未” - 需要复用聚合结果：比如既要取 Top 3，又要算标准差 → 同一层无法引用
SUM(x)别名做新计算，必须用CTE或子查询固化中间结果 - 子查询必须加别名：MySQL/PostgreSQL 都强制要求，漏掉
AS t会报Every derived table must have its own alias
二次计算时最容易忽略的三个防御点
不是语法错，是上线后突然 NULL 或除零崩溃。这些不是可选项，是必填项。
-
NULLIF(denominator, 0)必加：哪怕业务说“成本不可能为 0”，数据库只看运行时值；不加就可能SUM(revenue) / SUM(cost)直接报错 -
COALESCE(..., 0)看场景：如果某组无数据（如新部门没人），SUM(salary)返回NULL，后续参与除法或比较会传播NULL；补 0 还是留NULL，取决于业务定义 -
ROUND(..., 4)别省：浮点误差在毛利率、转化率这类指标上会放大，前端显示 29.999999% 还是 30%，差别就在这一轮四舍五入
真正容易翻车的，不是不会写 HAVING，而是没意识到它只负责“筛组”，不负责“跨组比”“复用结果”“防 NULL”。一旦逻辑超出单组边界，就得立刻切到子查询或 CTE，而不是硬塞条件进去。
