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是为了“让语句跑通”，但真正该问的是：“这个条件，是在分组前就能筛掉数据，还是必须等统计完才能判断？”
