WHERE在GROUP BY前执行，无法使用COUNT(*)等聚合函数；HAVING在分组后执行，可安全使用聚合函数筛选分组结果，二者必须配合使用，不可互相替代。
WHERE不能用聚合函数，必须用HAVING
直接写 WHERE COUNT(*) > 5 会报错，因为 COUNT(*) 还没算出来——WHERE 执行在 GROUP BY 之前，此时数据库连“有多少组”都不知道。只有 HAVING 在分组完成、聚合值就绪后才执行，所以它能安全使用 COUNT()、SUM(amount)、AVG(score) 等。
常见错误现象：
-
ERROR: column "status" must appear in the GROUP BY clause or be used in an aggregate function—— 把status = 'paid'错写进HAVING，而status又没出现在GROUP BY或聚合里 -
Unknown column 'cnt' in 'having clause'—— 在HAVING中用了SELECT COUNT(*) AS cnt的别名，PostgreSQL/SQL Server 不认，得写成HAVING COUNT(*) > 10
WHERE 和 HAVING 必须配合使用，不能只靠一个
想查“2024 年下单超 3 次的已支付用户”，必须拆成两步：先用 WHERE 剔掉无关行（减少分组压力），再用 HAVING 筛组（逻辑不可替代）。
-
WHERE负责：时间范围（order_date >= '2024-01-01'）、状态（status = 'paid'）、ID 范围等原始字段条件 -
HAVING负责：聚合结果判断（COUNT(*) >= 3）、组合表达式（AVG(price) * COUNT(*) > 500）、分组字段本身（category = 'electronics'，前提是它在GROUP BY中） - 把本该放
WHERE的条件塞进HAVING，比如HAVING status = 'paid'，会导致数据库对所有订单（含 cancelled）先分组，再丢弃——性能明显下降
HAVING 后不能引用未分组也未聚合的普通列
HAVING 的作用域很窄：只能用 GROUP BY 中出现的列、聚合函数、常量，以及它们的组合表达式。它不是 WHERE 的翻版。
- 合法：
HAVING SUM(amount) > 10000、HAVING category = 'books'（若GROUP BY category）、HAVING COUNT(*) * AVG(rating) > 20 - 非法：
HAVING user_name = 'Alice'（user_name没GROUP BY也没聚合）、HAVING price > 100（price是明细字段，每组有多个值，无法直接比） - 如果真要按明细字段过滤后再分组，得用子查询或 CTE 先处理，比如：
SELECT dept, AVG(salary) FROM (SELECT * FROM emp WHERE salary BETWEEN 5000 AND 80000) t GROUP BY dept
隐式单一分组时 HAVING 的行为差异
不写 GROUP BY 却用了聚合函数（如 SELECT COUNT(*) FROM t），整条语句会隐式变成“全表为一组”，此时 HAVING 语法上允许，但跨库兼容性差。
- MySQL 默认接受
SELECT 1 FROM orders HAVING COUNT(*) > 1000 - PostgreSQL 要求显式写
GROUP BY ()，否则报错：column "orders.id" must appear in the GROUP BY clause - 这种写法本质是聚合判断，不是常规分组场景；真要检查存在性，
EXISTS更清晰、性能通常更好 - 上线前务必在目标数据库验证，别依赖 MySQL 的宽松行为
