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 和所有聚合函数全部跑完，才轮到它出手。这个“等”的代价，在千万级表上就是秒级延迟。
