WHERE不能用COUNT()等聚合函数，因为SQL执行顺序为WHERE→GROUP BY→HAVING，聚合结果在WHERE阶段尚未生成；HAVING作用于分组后的结果集，可安全使用COUNT(*)、AVG()等，并支持SELECT中定义的别名。
WHERE 不能用 COUNT()，但 HAVING 可以
这是最常踩的坑：在 WHERE 子句里写 COUNT(*) > 5，MySQL 直接报错 Invalid use of group function。因为 SQL 执行顺序是 WHERE → GROUP BY → HAVING，聚合函数在 WHERE 阶段根本还没算出来。
-
WHERE看的是每一行原始数据，只能用表中已存在的列，比如salary > 8000、status = 'active' -
HAVING看的是分组后的“总结报告”，才能用COUNT(*)、AVG(price)、SUM(amount)这类结果 - 哪怕你只是想筛选“订单数大于 3 的用户”，也必须用
GROUP BY user_id+HAVING COUNT(*) > 3，不能省略GROUP BY
SELECT user_id, COUNT(*) AS order_count FROM orders WHERE created_at >= '2025-01-01' -- ✅ 先筛掉旧订单（走索引快） GROUP BY user_id HAVING COUNT(*) > 3; -- ✅ 再筛出高频用户（COUNT 此时已存在）
WHERE 过滤能走索引，HAVING 基本不走
性能差异非常真实：如果条件字段有索引，WHERE 可以在磁盘读取阶段就跳过大量数据；而 HAVING 是等所有数据加载进内存、分完组、算完聚合后才过滤，IO 和 CPU 开销都大得多。
- 能放进
WHERE的条件，绝不挪到HAVING—— 比如status = 'paid'、region IN ('CN', 'JP') -
HAVING只保留真正依赖聚合结果的逻辑，例如HAVING AVG(score) >= 90 - 关联查询中更明显：
WHERE先过滤再 JOIN，HAVING是 JOIN 完再过滤，中间临时结果集可能暴涨几倍
HAVING 能用别名，WHERE 不能
这是语法上一个很实用但容易被忽略的细节：在 SELECT 中定义的字段别名，在 HAVING 中可以直接引用；而 WHERE 会报 Unknown column 'xxx' in 'where clause'。
- ✅ 合法：
SELECT department, AVG(salary) AS avg_sal FROM emp GROUP BY department HAVING avg_sal > 15000 - ❌ 报错：
WHERE avg_sal > 15000—— 别名在WHERE阶段还不存在 - 想在
WHERE里用计算值？只能重复表达式，比如WHERE AVG(salary) > 15000（但这样又非法，因为WHERE不允许聚合）→ 所以别无选择，必须用HAVING
没写 GROUP BY 时，HAVING 还能用吗？
可以，但意义变了：此时整张表被当成“一个组”，HAVING 就相当于对全表聚合结果做判断。虽然合法，但容易引发误解和维护风险。
- ✅ 有效（但慎用）：
SELECT COUNT(*) AS total FROM users HAVING total > 10000—— 返回空结果集或一行 - ⚠️ 问题：语义模糊，不如用
SELECT COUNT(*) > 10000加应用层判断清晰 - ❌ 不推荐替代
WHERE：比如想查“是否存在活跃用户”，写成SELECT 1 FROM users HAVING MAX(last_login) > NOW() - INTERVAL 7 DAY就绕远路了
聚合函数只在分组后才有意义，而 HAVING 是唯一能安全触碰它们的子句——不是语法限制，是执行顺序决定的刚性约束。很多人调换 WHERE 和 HAVING 是为了“让语句跑通”，但真正该问的是：“这个条件，是在分组前就能筛掉数据，还是必须等统计完才能判断？”