WHERE过滤分组前的行，HAVING过滤分组后的组；WHERE用于筛原始数据（如salary>5000的员工），HAVING用于筛聚合结果（如AVG(salary)>5000的部门），且HAVING必须配合GROUP BY使用。
WHERE 和 HAVING 到底谁该过滤什么
WHERE 在分组前筛行，HAVING 在分组后筛组——这是最常被颠倒的逻辑起点。很多人写 HAVING 是因为 WHERE 报错“不能用聚合函数”，但没意识到自己其实想筛原始数据，不是组。
常见错误现象：SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING salary > 5000 —— 这会报错或结果诡异，因为 salary 在分组后已不单值，且未出现在 GROUP BY 或聚合中。
- 想筛“工资大于 5000 的员工”？用
WHERE salary > 5000 - 想筛“平均工资大于 5000 的部门”？才用
HAVING AVG(salary) > 5000 -
HAVING后只能出现：聚合函数（AVG()、COUNT()等）、GROUP BY中的列、或这些的组合表达式
HAVING 必须配合 GROUP BY 使用吗
是。没有 GROUP BY，SQL 默认把整张表当一个组，此时 HAVING 虽语法允许，但极易误导——它看起来像“全局过滤”，实际是“对单个隐式组做条件判断”。这种写法可读性差，且多数数据库（如 PostgreSQL）会直接拒绝无 GROUP BY 的 HAVING。
使用场景：极少数需要“全表聚合后判断”的情况，比如 SELECT COUNT(*) FROM log HAVING COUNT(*) > 1000（检查日志条数是否超限）。但更推荐用子查询或应用层判断，避免滥用。
- MySQL 允许无
GROUP BY的HAVING，但行为不一致，慎用 - SQLite 和 SQL Server 通常报错：
misuse of aggregate: COUNT()或类似提示 - 只要写了
HAVING，就默认你清楚自己在操作分组结果
ORDER BY 和 HAVING 的执行顺序容易搞混
执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着 HAVING 看不到 SELECT 中定义的别名，也影响不到 ORDER BY 的排序依据——但 ORDER BY 可以用聚合结果，因为它在 HAVING 之后。
Joker AIx
一站式AI创意生产平台，覆盖图像、视频、音频、文案全品类创作
下载
常见错误现象：SELECT dept, AVG(salary) AS avg_sal FROM emp GROUP BY dept HAVING avg_sal > 5000 ORDER BY avg_sal DESC —— 这里 avg_sal 在 HAVING 中非法（别名不可用），必须写成 HAVING AVG(salary) > 5000。
-
HAVING中不能用SELECT别名，只能用原始列或聚合表达式 -
ORDER BY中可以用别名，也可以用聚合函数，甚至可以排序未出现在SELECT中的字段（只要它在GROUP BY中） - 性能上，
HAVING越早筛掉无效组，后续计算越少；但别指望它替代索引，分组本身已是较重操作
NULL 值和空组在 HAVING 中的陷阱
HAVING 条件对 NULL 的处理和 WHERE 一样：任何与 NULL 的比较（>、=、!=）都返回 UNKNOWN，不满足条件，该组会被排除。这会导致“明明有数据却查不到结果”的困惑。
使用场景：统计非空部门的平均薪资时，若 dept 字段有 NULL，对应记录会被分到单独一组（GROUP BY dept 下 NULL 自成一组），而 HAVING AVG(salary) > 5000 仍可能包含它——除非你显式排除。
- 要忽略
dept IS NULL的组，得加HAVING dept IS NOT NULL AND AVG(salary) > 5000 - 空表或全 NULL 分组时，
COUNT(*)返回 0，AVG()返回 NULL，HAVING COUNT(*) > 0才能确保至少有一行参与聚合 - 某些旧版 MySQL 在
sql_mode不严格时会把 NULL 当 0 处理，导致结果不一致，务必确认环境配置
HAVING 的核心就一条：它只认聚合结果和分组键，不认原始行、不认别名、不认未聚合的列。写之前先问自己——你要筛的是“哪些组”，而不是“哪些行”或者“哪些字段显示出来”。这点一旦模糊，后面所有调试都在绕弯。