WHERE不能使用聚合函数因执行顺序在分组前，应改用HAVING配合GROUP BY筛选分组结果；WHERE过滤原始行提升性能，HAVING作用于分组后结果集，二者可共存且分工明确。
WHERE 不能用 COUNT()、SUM() 这类聚合函数
因为 WHERE 在分组和聚合计算之前执行，此时 COUNT() 还没算出来，数据库直接报错。比如写 WHERE COUNT(*) > 5，MySQL、PostgreSQL、SQL Server 都会拒绝执行。
常见错误现象：
- 报错信息类似
Invalid use of aggregate function或ERROR 1111 (HY000): Invalid use of group function - 试图在
WHERE中引用SELECT里定义的别名（如avg_salary），也会失败——WHERE看不到SELECT的结果
正确做法是把这类条件挪到 HAVING 里，等分组完成、聚合值算出来之后再筛。
HAVING 必须配合 GROUP BY（或隐式单一分组）
HAVING 的作用对象是“分组后的结果集”，不是原始行。没有 GROUP BY 时，多数数据库（如 PostgreSQL、SQL Server）会报错；MySQL 和 SQLite 虽允许，但行为不一致——MySQL 把整张表当一个分组处理，SQLite 可能返回意外结果。
使用场景注意点：
- 想查“平均工资 > 8000 的部门”，必须写
GROUP BY dept，再加HAVING AVG(salary) > 8000 - 想查“全表平均工资是否 > 8000”，可以不写
GROUP BY，但这是边缘用法，可读性差，建议显式写GROUP BY ()或改用子查询 -
HAVING能用的字段仅限：出现在GROUP BY中的列，或聚合函数（如COUNT()、MAX()），不能直接用未分组的普通列（如salary）
WHERE 先过滤能显著提升性能
数据量越大，这个区别越明显。WHERE 在聚合前就把无关行干掉，后续 GROUP BY 和 HAVING 处理的数据量就小得多。
例如查“2023 年订单中，客户总消费超 1 万元的部门”：
- ✅ 推荐：
WHERE order_date >= '2023-01-01' AND order_date 先筛年份，再 <code>GROUP BY customer_id，最后HAVING SUM(amount) > 10000 - ❌ 反模式：把年份条件也塞进
HAVING，会导致数据库先对全部历史订单分组，再过滤——IO、内存、CPU 全浪费 - ⚠️ 注意：如果
HAVING里写的其实是分组键本身（如HAVING dept = 'HR'），应该无条件移到WHERE——这不算业务逻辑，纯属性能失误
WHERE 和 HAVING 可以同时出现，但不能互换
它们不是二选一，而是流水线上的两个不同工位：WHERE 负责“挑原料”，HAVING 负责“验成品”。典型组合就是先用 WHERE 缩小数据范围，再用 GROUP BY + HAVING 筛分组结果。
示例语句：
SELECT dept, COUNT(*) AS cnt, AVG(salary) AS avg_sal FROM employees WHERE status = 'active' GROUP BY dept HAVING AVG(salary) > 5000;
这里容易被忽略的是：如果某部门所有员工都被 WHERE 过滤掉了，那它根本不会出现在 GROUP BY 结果里，自然也不会被 HAVING 检查——HAVING 不会“看到”空分组。
