WHERE在分组前过滤原始字段，HAVING在分组后过滤聚合结果；WHERE中禁用COUNT()等聚合函数，否则报错或逻辑错误。
分组查询结果不对，八成是把过滤条件塞错位置了——WHERE 和 HAVING 混用是最常见的硬伤。
WHERE 里写了 COUNT() 就直接报错
这是最典型的错误现象：语句一执行就弹出 aggregate functions are not allowed in WHERE 或类似提示。比如写成：
SELECT department, COUNT(*) AS cnt FROM employees WHERE COUNT(*) > 5 GROUP BY department;
数据库根本不会等你分完组再算 COUNT()，它在 WHERE 阶段连“组”都还没形成，COUNT(*) 根本不存在。
-
WHERE只能访问原始表字段，如status、created_at - 所有聚合函数（
COUNT()、SUM()、AVG()）必须等到GROUP BY完成后才可用 - MySQL 5.7+ 在宽松模式下可能不报错，但结果不可靠，换到 PostgreSQL 或 SQL Server 立刻崩
HAVING 不能替代 WHERE 做前置过滤
有人觉得“反正都要过滤，放 HAVING 里也一样”，其实性能和逻辑都会出问题。比如查“2024 年订单数超 10 的客户”：
- ✅ 正确：
WHERE order_date >= '2024-01-01'放在GROUP BY前 → 先筛掉历史数据，再分组，快且准 - ❌ 错误：
HAVING order_date >= '2024-01-01'→ 报错，因为order_date没出现在GROUP BY列里，HAVING看不见它 - ⚠️ 更隐蔽的错：
HAVING COUNT(*) > 10虽然语法对，但如果漏写WHERE时间条件，数据库就得对全部年份数据分组，内存爆、速度慢、索引全失效
别名在 HAVING 中能不能用，看数据库
写 SELECT SUM(amount) AS total FROM orders GROUP BY user_id HAVING total > 5000，MySQL 会接受，PostgreSQL 会报错：
- MySQL 允许在
HAVING中使用SELECT里的列别名 - PostgreSQL、SQL Server、Oracle 要求写完整表达式：
HAVING SUM(amount) > 5000 - 跨库迁移时，这种写法是隐形雷——不是语法错，是行为不一致
- 建议统一用原始表达式，避免依赖方言特性
真正容易被忽略的是作用域：WHERE 看不到分组结果，HAVING 看不到未分组也未聚合的字段。一旦混淆，查出来的数据和业务需求对不上，还很难定位——因为语句能跑通，只是逻辑错了。
