WHERE在GROUP BY前执行，只能用原始字段；HAVING在分组后执行，必须配合GROUP BY，用于过滤聚合结果，且多数数据库不支持在HAVING中使用SELECT别名。
WHERE 和 HAVING 的执行顺序决定了它们能用什么条件
WHERE 在分组（GROUP BY）之前过滤行，所以它只能用原始表里的字段，不能用 AVG()、COUNT() 这类聚合函数；HAVING 在分组之后过滤组，因此必须等分组完成、聚合计算结束才能生效。
常见错误是把本该放 HAVING 的条件写进 WHERE，比如：WHERE COUNT(*) > 5 —— 这会直接报错，因为 COUNT(*) 此时还没算出来。
-
WHERE可以用：原始列（如status、created_at）、普通表达式（如price > 100） -
HAVING必须用：聚合结果（如COUNT(id)、AVG(score)）、或已出现在GROUP BY中的列 - 如果既要按原始字段过滤，又要按聚合结果过滤，两个子句要同时出现，且
WHERE必须在GROUP BY前
HAVING 必须配合 GROUP BY 使用，否则没意义
单独写 HAVING COUNT(*) > 1 而不加 GROUP BY，在大多数数据库（如 MySQL 5.7+ 严格模式、PostgreSQL）里会报错，提示“HAVING without GROUP BY”或类似错误。
MySQL 旧版本可能允许，但行为等价于对整张表聚合成单组，容易造成误解。实际业务中几乎不会这么用。
- 想查“哪些用户发了超过 3 条评论”，必须写：
GROUP BY user_id HAVING COUNT(*) > 3 - 想查“所有评论总数是否超 100”，应该用
SELECT COUNT(*) FROM comments，而不是靠HAVING - 有些 ORM 或 BI 工具生成的 SQL 会漏掉
GROUP BY，导致 HAVING 失效或报错，需要人工核对
聚合字段别名在 HAVING 中不能直接用（多数数据库）
很多人习惯给聚合字段起别名，比如 SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept HAVING cnt > 10，但在 PostgreSQL、SQL Server、Oracle 中，这会报错：“cnt does not exist” —— 因为 HAVING 执行时，SELECT 列别名还不可见。
MySQL 是个例外，默认允许（但开启 ONLY_FULL_GROUP_BY 后也会报错），所以依赖别名写法不跨库。
- 安全写法：在
HAVING中重复聚合表达式，例如HAVING COUNT(*) > 10 - 或者用子查询/CTE 先算出聚合值，再在外层用别名过滤
- 如果用的是 MySQL 且确认兼容性，可保留别名，但上线前务必在目标环境验证
性能上，WHERE 越早过滤，HAVING 越少计算
WHERE 能减少参与分组的原始行数，直接影响 GROUP BY 的数据量和内存占用；HAVING 是对已分好的组做筛选，无法减少分组过程本身开销。
比如查“2024 年下单超 5 次的 VIP 用户”，应把时间过滤和身份过滤都放在 WHERE，而不是拖到 HAVING：
SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' AND created_at >= '2024-01-01' AND is_vip = 1 GROUP BY user_id HAVING COUNT(*) > 5
如果把 is_vip = 1 放进 HAVING，数据库就得先对全部订单分组，再逐组判断，效率明显下降。
特别注意：某些复杂条件（比如涉及多表 JOIN 后的字段）可能被迫放到 HAVING，这时得权衡逻辑正确性和性能，必要时加索引或改用临时表预处理。
