在SQL查询中，我们经常需要先按某个字段分组，再对每组的统计结果进行筛选。比如统计每个用户的订单总数，只保留下单超过5次的用户。很多人在写这种需求时，会习惯性地把筛选条件放在WHERE后面，结果数据库直接报无效使用分组函数的错误。根本原因在于WHERE和HAVING在查询执行流程中处于不同阶段，职责完全不同。
一、WHERE与HAVING的执行顺序差异
标准SQL的查询子句执行顺序大致是：FROM确定数据源，WHERE过滤原始行，GROUP BY进行分组，HAVING过滤分组结果，SELECT投影列，ORDER BY排序。可以看到，WHERE发生在GROUP BY之前，此时还没有分组，也没有聚合值，所以WHERE里不能出现COUNT、SUM等聚合函数。而HAVING位于GROUP BY之后，它能够访问分组产生的聚合结果，因此专门用来过滤分组。
用一个形象的比喻：WHERE是在把材料送进机器加工前挑出合格的原料，HAVING是在机器把原料分成若干堆并算出每堆重量后，把不够重的堆扔掉。如果试图在挑原料时就按重量扔堆，机器还没运转，自然做不到。这种顺序差异不是数据库厂商的随意设计，而是关系代数理论决定的，所有主流关系型数据库都遵循。
1.1 错误写法示例
下面这段代码试图在WHERE中使用聚合函数，在MySQL等数据库中会直接报错：
SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE COUNT(*) > 5 GROUP BY user_id;
报错信息通常是“无效使用分组函数”或“聚合函数不能在WHERE子句中使用”。因为数据库先执行WHERE，此时连分组都还没做，COUNT(*)无从计算。
1.2 正确写法示例
把条件移到HAVING子句中即可正常运行：
SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING COUNT(*) > 5;
这条语句先按user_id分组并算出每组的订单数，再用HAVING保留订单数大于5的分组。逻辑清晰，执行稳定。
二、HAVING配合聚合函数的常见用法
HAVING后面不仅可以跟简单的聚合比较，还能组合多个条件，或者使用SELECT中定义的别名（部分数据库支持）。实际业务中，统计类过滤往往比单一条件复杂。
例如，我们想找出总消费金额超过一千元且下单次数不少于三次的用户，可以用AND连接两个聚合条件：
SELECT user_id,
COUNT(*) AS order_cnt,
SUM(amount) AS total_amount
FROM orders
GROUP BY user_id
HAVING SUM(amount) > 1000 AND COUNT(*) >= 3;
这里SUM(amount)和COUNT(*)都是分组后计算出的统计值，HAVING在分组结果集上逐行判断，只有同时满足两个条件的分组才会被返回。这种写法比先查出来再用程序过滤更高效，因为过滤发生在数据库引擎内部，减少了网络传输的数据量。
2.1 HAVING中使用别名的问题
在MySQL中，HAVING可以直接使用SELECT里的别名，如HAVING order_cnt > 5；但在Oracle和PostgreSQL中，HAVING子句执行时机早于SELECT投影，不能直接用别名，必须重复写聚合函数。为了兼容性和可读性，建议在不确认数据库特性时，于HAVING中写完整的聚合表达式。
-- MySQL可写 SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING order_cnt > 5; -- 标准兼容写法 SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING COUNT(*) > 5;
两种写法结果一致，但后者在迁移到不同数据库时不会报错，是更稳妥的选择。
三、WHERE与HAVING能否同时使用
二者不仅能同时存在，而且合理搭配能显著提升性能。WHERE先过滤掉不需要的原始行，减少分组计算量；HAVING再对分组结果做精细过滤。
假设订单表有十年数据，但我们只关心2023年以后的高频用户，应当把时间过滤放WHERE，把次数过滤放HAVING：
SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE order_date >= '2023-01-01' GROUP BY user_id HAVING COUNT(*) > 10;
如果反过来把order_date也放进HAVING，数据库就得先把全部历史订单分组，再扔掉不符合时间的组，白白消耗大量CPU和内存。因此经验原则是：能先用WHERE过滤的行级条件，绝不留到HAVING；只有依赖聚合结果的过滤才用HAVING。
3.1 性能对比示意
| 写法 | 扫描行数 | 分组基数 | 适用场景 |
|---|---|---|---|
| 仅HAVING过滤时间 | 全表 | 全部分组 | 无索引且必须全量统计 |
| WHERE过滤时间+HAVING过滤统计 | 索引命中局部 | 局部分组 | 绝大多数业务查询 |
从表中可见，组合使用能让分组基数大幅下降。在千万级订单表上，这种写法往往带来十倍以上的耗时差距。
四、易混淆点：HAVING后能跟非聚合列吗
在标准SQL中，HAVING子句要么引用聚合函数，要么引用出现在GROUP BY中的列。因为分组后非分组列在每个组里可能有多个值，无法判定用哪一个做过滤。不过MySQL在宽松模式下允许写出HAVING non_group_column = x，此时它隐式取每组第一行的值，行为不稳定，不建议依赖。
-- 标准安全写法：status在GROUP BY中 SELECT user_id, status, COUNT(*) AS cnt FROM orders GROUP BY user_id, status HAVING status = 'paid' AND COUNT(*) > 1;
将status加入GROUP BY后，每组内的status唯一，HAVING引用它就完全合法，语义也清晰：只保留已支付分组中订单数大于1的记录。
五、总结与实践建议
分组后过滤统计结果必须用HAVING，这是SQL语法层的硬性约束，也是查询优化的重要切入点。写统计SQL时，先想清楚条件依赖的是原始行还是聚合值：依赖原始行用WHERE，依赖统计值用HAVING，两者各司其职又可协作。掌握这一区分，就能避免常见的分组报错，也能写出更高效的报表查询。
建议在复杂统计需求中，先用纸笔列出“分组键、聚合指标、行级过滤、组级过滤”四要素，再落笔写SQL。这样思路不易乱，HAVING和WHERE也不会放错位置。遇到数据库报错无效分组函数时，第一反应应是检查是否把聚合条件误写进了WHERE。