having必须跟在group by后，不可独立使用；筛选全局聚合需显式group by ()；where应在group by前过滤，having仅用于组内条件；order by可引用having中的聚合别名但需注意兼容性；复杂逻辑需用子查询、窗口函数等替代having。
HAVING 必须跟在 GROUP BY 后面，不能独立使用
没写 GROUP BY 却直接用 HAVING，多数数据库会拒绝执行（PostgreSQL 严格报错，MySQL 5.7+ 在 ONLY_FULL_GROUP_BY 开启时也报错）。哪怕你只想筛一个全局聚合值，比如 SELECT COUNT(*) FROM orders HAVING COUNT(*) > 1000，也应显式写成 GROUP BY ()。隐式单一分组写法跨库不兼容，迁移或换数据库时容易崩。
常见错误现象：
-
HAVING user_id > 100报Unknown column 'user_id' in 'having clause'—— 因为user_id没出现在GROUP BY列表里，也没被聚合包裹 -
SELECT dept, AVG(salary) FROM employees HAVING AVG(salary) > 10000在 MySQL 严格模式下失败 ——dept既没分组也没聚合，SELECT 不合法
WHERE 和 HAVING 必须配合使用，顺序不能乱
想查“2024 年下单超 5 次的活跃客户”，得先用 WHERE 把无关数据砍掉，再分组，最后用 HAVING 筛组。顺序错了，性能和结果都出问题。
正确结构：
-
WHERE order_date >= '2024-01-01' AND status = 'completed'—— 先筛时间与状态，减少输入行数 -
GROUP BY customer_id—— 再按客户分组 -
HAVING COUNT(*) > 5—— 最后筛出高频客户
反例：HAVING order_date >= '2024-01-01' 是错的 —— order_date 没参与分组，也没聚合，HAVING 无法引用；而且它本该在分组前就由 WHERE 处理，放这里等于全表分完组再丢弃，白白消耗 CPU 和内存。
ORDER BY 引用聚合别名要小心 NULL 和精度
HAVING 过滤完的结果，才是 ORDER BY 的输入源。所以 ORDER BY 能用 HAVING 里出现的聚合表达式或别名，但要注意两个坑：
- 如果
SELECT中用了ROUND(AVG(score), 2) AS avg_score，那么ORDER BY avg_score没问题，但HAVING avg_score > 4.5在部分旧版 MySQL 中不被支持，得写成HAVING ROUND(AVG(score), 2) > 4.5 -
ORDER BY COUNT(*) DESC没问题，但如果某组因WHERE条件过滤后为空，COUNT(*)就是 0，排序时它会排在最前（升序）或最后（降序），未必是你想要的“有效组”顺序
复杂逻辑超出 HAVING 能力时，别硬扛
HAVING 只能做“组内判断”，没法跨组比较、没法否定、没法带状态。比如：
- 查“销售额高于所有部门平均值的部门” → 必须用子查询：
HAVING SUM(amount) > (SELECT AVG(total) FROM (SELECT SUM(amount) AS total FROM sales GROUP BY dept) t) - 查“买过 iPhone 但没买过 AirPods 的用户” →
HAVING表达不了“未购买”，得用NOT EXISTS或LEFT JOIN ... IS NULL - 查“连续 3 个月订单额破万的销售员” → 需要窗口函数或 CTE 标记月份序列，
HAVING无状态，做不到
真正容易被忽略的是：HAVING 本身不走索引，所有计算都在内存完成。优化重点永远在前面——用好 WHERE 缩小数据集，确保 GROUP BY 字段有索引，而不是指望 HAVING 做性能兜底。
