WHERE不能用聚合函数，因其执行早于GROUP BY和聚合计算；正确做法是将聚合条件移至HAVING子句，且HAVING必须配合GROUP BY使用。

WHERE 不能用聚合函数，否则报错

执行顺序决定了 WHERE 只能看到原始表里的字段，还没算出 COUNT(*)、SUM(amount) 这些值。所以写 WHERE COUNT(*) > 5 或 WHERE AVG(salary) > 8000 会直接报语法错误。

常见错误现象：

• Unknown column 'COUNT(*)' in 'where clause'（MySQL）
• GROUP BY clause is required before using aggregate functions（PostgreSQL）

正确做法是把这类条件挪到 HAVING 里，前提是已加 GROUP BY。

HAVING 必须跟 GROUP BY 一起出现

HAVING 不是独立子句，它依赖分组结果存在。单独写 SELECT * FROM orders HAVING amount > 1000 会报错，因为没分组，也就没有“组”可过滤。

使用场景包括：

• 查平均订单额超 5000 的部门：GROUP BY dept_id HAVING AVG(amount) > 5000
• 查下单次数大于 3 的客户：GROUP BY customer_id HAVING COUNT(*) > 3

注意：SQLite 虽然允许不写 GROUP BY 直接用 HAVING，但行为不可靠，别依赖。

HAVING 能用别名，WHERE 不能

SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING total > 10000 是合法的——total 是 SELECT 中定义的别名，HAVING 能认。

但 WHERE total > 10000 一定报错，因为 WHERE 执行时 total 还没生成。

这个差异背后是执行流程：FROM → WHERE → GROUP BY → HAVING → SELECT。别名只在 SELECT 阶段才绑定，所以只有 HAVING 和之后的子句能用。

WHERE 条件漏进 HAVING 会导致性能变差

比如想查「部门 ID 为 1 且该部门员工数大于 2」，写成：

SELECT dept_id, COUNT(*) 
FROM employees 
GROUP BY dept_id 
HAVING dept_id = 1 AND COUNT(*) > 2;

数据库会先对全表分组，再丢掉除 dept_id=1 外的所有组——白算一堆聚合。

应该写成：

SELECT dept_id, COUNT(*) 
FROM employees 
WHERE dept_id = 1 
GROUP BY dept_id 
HAVING COUNT(*) > 2;

这样 WHERE 先筛出行，再分组，数据量小，快得多。

容易被忽略的一点：HAVING 里出现的非聚合字段（如 dept_id），如果它也在 GROUP BY 列表中，几乎总该优先移到 WHERE 里——除非你真需要先分组再筛组。