WHERE不能用COUNT()等聚合函数，因其在分组前执行；HAVING才用于过滤聚合结果，且可使用SELECT中的别名，性能上WHERE优先剪枝更高效。
WHERE 不能用 COUNT()，一写就报错
这是最常踩的坑：想查“订单数超 5 的用户”，却把聚合条件硬塞进 WHERE：SELECT user_id, COUNT(*) FROM orders WHERE COUNT(*) > 5 GROUP BY user_id。MySQL 直接报错 Invalid use of group function——因为 WHERE 在分组和聚合计算之前执行，此时 COUNT(*) 根本还没算出来。
- WHERE 只能过滤原始表里的字段，比如
status = 'paid'、created_at > '2025-01-01' - HAVING 才是专为聚合结果设计的，必须等
GROUP BY完成、COUNT()/SUM()算出值之后才生效 - 正确写法是：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING cnt > 5
HAVING 可以用别名，WHERE 不行
在 SELECT 中定义的字段别名（如 COUNT(*) AS total），WHERE 看不见，HAVING 却可以直接用——这是语法层面的硬限制，不是风格偏好。
- ✅ 合法：
SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING total > 1000 - ❌ 报错：
... WHERE total > 1000（Unknown column 'total' in 'where clause'） - ⚠️ 注意：哪怕你把
SUM(amount)原样抄进 WHERE，也一样错——WHERE SUM(amount) > 1000同样触发Invalid use of group function
性能差得明显：WHERE 先剪枝，HAVING 后筛渣
WHERE 能走索引、跳过磁盘读取；HAVING 是等所有分组都算完，再把结果一条条比对——数据量一大，延迟立刻可见。
- 能放 WHERE 的，坚决不放 HAVING：比如时间范围、状态过滤、非空校验，全往前挪
- 例如查“2025 年下单且人均消费 > 500 的客户”：
WHERE order_date >= '2025-01-01'必须在 GROUP BY 前，HAVING AVG(amount) > 500才放后面 - 没 GROUP BY 时用 HAVING（如
SELECT COUNT(*) HAVING COUNT(*) > 1000）纯属炫技，语义模糊、难调试，应用层判断更直白
没 GROUP BY 时 HAVING 也能用，但别用
语法上允许，语义上危险。整张表被当成一个大分组，HAVING 就成了“全局聚合后过滤器”。它不报错，但容易误导人以为还能做行级筛选。
- ✅ 语法合法：
SELECT COUNT(*) AS n FROM users HAVING n > 5000 - ❌ 实际效果：要么返回一行，要么空集；无法做任何中间态处理
- ? 更靠谱的做法是：
SELECT COUNT(*) FROM users拿到数字后，在代码里判断，或用子查询：SELECT * FROM (SELECT COUNT(*) AS n FROM users) t WHERE t.n > 5000
真正卡住人的，从来不是“HAVING 能不能用聚合函数”，而是它那不可绕过的执行时机——必须等 GROUP BY 和所有聚合函数全部跑完，才轮到它出手。这个“等”的代价，在千万级表上就是秒级延迟。
