不能用WHERE过滤分组后的结果，因为WHERE在GROUP BY之前执行，此时聚合函数尚未计算且数据未分组，导致含聚合函数的条件（如COUNT(*)>10）会报错；必须用HAVING在GROUP BY之后过滤分组结果。
为什么不能用WHERE过滤分组后的结果
因为WHERE在GROUP BY之前执行，此时聚合函数（如COUNT()、SUM()）还没计算，字段也尚未按组归并。你写WHERE COUNT(*) > 10会直接报错：ERROR: aggregate functions are not allowed in WHERE。
常见错误现象包括：
- MySQL 报错
Invalid use of group function - PostgreSQL 提示
column must appear in the GROUP BY clause or be used in an aggregate function（其实是误放了聚合条件到 WHERE） - 查询返回空结果，但逻辑上应有数据——可能因 WHERE 过早剔除了原始行，导致某些组根本没生成
HAVING 必须紧跟 GROUP BY 之后
HAVING不是可选修饰，是语法硬性要求：它只能出现在GROUP BY之后、ORDER BY或LIMIT之前。执行顺序固定为：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。
实操要点：
- 所有含聚合函数的条件（如
HAVING AVG(score) >= 60）必须放这里 - 可以复用
SELECT中的别名，比如SELECT dept, AVG(salary) AS avg_sal FROM emp GROUP BY dept HAVING avg_sal > 5000是合法的 - 不支持字段别名的旧版 MySQL（5.7 以前）需重复表达式：
HAVING AVG(salary) > 5000，而非别名
WHERE 和 HAVING 要配合着用，不是二选一
真正高效的写法往往是先用WHERE缩小原始数据集，再用HAVING筛组。比如查“2023 年订单总额超 1 万的客户”：
SELECT customer_id, SUM(amount) AS total FROM orders WHERE order_date >= '2023-01-01' -- 先剔除旧数据，减少分组压力 GROUP BY customer_id HAVING SUM(amount) > 10000; -- 再筛出高价值客户组
关键区别：
-
WHERE过滤的是行，影响GROUP BY输入规模；HAVING过滤的是组，影响输出行数 - 把本该放
WHERE的条件错放HAVING（比如HAVING status = 'paid'），会导致数据库对每组都做字符串比对，性能明显下降 - 若条件不含聚合函数，优先放
WHERE——这是明确的性能优化点，不是风格偏好
容易被忽略的 NULL 和空组问题
HAVING不会自动跳过 NULL 值，但聚合函数（如AVG()、COUNT()）本身对 NULL 有默认行为。例如：
-
HAVING COUNT(col) > 0和HAVING COUNT(*) > 0效果不同：前者只统计非 NULL 行，后者统计所有行 - 如果某组所有
col值都是 NULL，AVG(col)返回 NULL，HAVING AVG(col) > 100会把这个组整个排除（因为 NULL > 100 为 UNKNOWN） - 想保留 NULL 组？得显式写
HAVING AVG(col) > 100 OR AVG(col) IS NULL，但通常这不是你想要的逻辑
最常踩的坑是以为HAVING能“补救”分组前漏掉的数据——它不能。如果原始数据里就没有某类记录，那组根本不会出现，HAVING无从下手。这时候得回头检查WHERE是否过于激进。
