在MySQL查询里，HAVING子句常常被初学者忽略或者误用。它并不是WHERE的替代品，而是专门配合GROUP BY完成分组后过滤的关键字。理解它的运作时机，是写出正确统计SQL的基础。
HAVING与WHERE的核心差异
很多人在写带分组的查询时，搞不清到底该把条件放在WHERE还是HAVING中。根本区别在于：WHERE在分组之前过滤原始数据行，它不能识别聚合函数；HAVING在GROUP BY分组完成之后，对聚合结果进行过滤，因此可以使用COUNT、SUM、AVG等函数。
从SQL执行顺序来看，MySQL大致按照FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY的步骤走。也就是说，WHERE先削减参与分组的行数，提升效率；HAVING再基于汇总值剔除不符合要求的组。如果把聚合条件错放到WHERE里，解析器会因为还没有分组而直接报无效使用的错误。
一个容易踩坑的例子
假设我们有一张订单表orders，字段包括user_id和amount。现在要找累计消费大于500的用户，下面这种写法就是错的：
SELECT user_id, SUM(amount) AS total FROM orders WHERE SUM(amount) > 500 GROUP BY user_id;
上面的语句会把SUM放在WHERE中，MySQL会提示非法使用组函数。正确做法是把汇总过滤挪到HAVING：
SELECT user_id, SUM(amount) AS total FROM orders WHERE 1 = 1 GROUP BY user_id HAVING SUM(amount) > 500;
这里WHERE虽然写了看似无用的条件，但主要是为了展示位置。实际中若无需行级过滤，可以省略WHERE直接GROUP BY。
HAVING的基本语法与示例
HAVING的语法结构和WHERE类似，只是它紧跟在GROUP BY之后，并且条件中允许出现聚合表达式或者SELECT里定义的别名（取决于MySQL版本配置）。最基本的形式如下：
SELECT 列或聚合函数 FROM 表 GROUP BY 分组列 HAVING 聚合条件;
我们沿用orders表，统计每个用户的订单笔数，并只保留下单超过3次的人：
SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING COUNT(*) > 3;
这条语句先按user_id切分数据，算出每组的行数，再筛掉order_cnt不超过3的组。结果集里就只剩高频用户。这种写法在运营报表里非常普遍。
在HAVING中使用别名
在标准SQL中，HAVING通常不能使用SELECT里定义的别名，因为SELECT在HAVING之后执行。但MySQL做了扩展，默认允许在HAVING中引用别名，方便书写：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id HAVING cnt > 3;
虽然上面语句能跑通，但为了兼容其他数据库，建议生产环境尽量写聚合函数原名。另外，HAVING后也能用AND、OR连接多个条件，比如同时限制笔数和总额：
SELECT user_id, COUNT(*) AS cnt, SUM(amount) AS total FROM orders GROUP BY user_id HAVING cnt > 3 AND total > 100;
没有GROUP BY时能用HAVING吗
严格来说，HAVING是为分组设计的，但如果查询里没有GROUP BY，MySQL会把整张表当作一个组，此时HAVING相当于对全局聚合结果的过滤。这种写法虽合法，但语义上接近用子查询包一层。
SELECT COUNT(*) AS all_cnt FROM orders HAVING all_cnt > 100;
上面语句返回总订单数，且只有在大于100时才出结果，否则为空集。不过这种场景用WHERE 1=1配合子查询或简单判断可读性更好，不建议滥用。
和子查询的取舍
有些复杂过滤既可以用HAVING，也可以用先聚合再WHERE的子查询。比如先算出用户总额子表，再过滤：
SELECT user_id, total FROM ( SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id ) t WHERE total > 500;
两种写法结果一致。HAVING更简洁，子查询更通用。在只需要简单分组过滤时，HAVING性能通常也不差，因为分组动作不可避免；但多层嵌套时，子查询结构更清晰，也方便后续加 JOIN。
常见错误与排查建议
使用HAVING时，最频繁的错误就是把非聚合列放进HAVING却没在GROUP BY里。MySQL在宽松模式下可能不报错而是随便取一行，导致数据误导。务必保证HAVING条件里的普通列要么在GROUP BY中，要么是聚合包裹的。
-- 错误示范：amount既没聚合也不在GROUP BY SELECT user_id, amount FROM orders GROUP BY user_id HAVING amount > 10;
另外，HAVING里引用了SELECT别名却遇到ONLY_FULL_GROUP_BY模式开启的库，可能报错，这时改回聚合函数即可。调试时，可先去掉HAVING跑分组，确认每组数值符合预期，再加回过滤条件逐步验证。
| 对比项 | WHERE | HAVING |
|---|---|---|
| 执行阶段 | 分组前 | 分组后 |
| 能否用聚合函数 | 否 | 是 |
| 作用对象 | 原始行 | 分组结果 |
| 性能影响 | 减少分组数据量 | 不影响分组前开销 |
掌握这些区别后，面对统计需求就能准确落笔。记住：行级筛选交给WHERE，组级汇总筛选交给HAVING，两者互补而非竞争。