最近跟几个做数据分析的朋友聊天，发现一个挺有意思的现象：很多人都知道SQL里有个 HAVING 子句，但真到实战中，要么不敢用，要么用错了地方。其实 HAVING 就像你工具箱里的一把梅花扳手——平时用得不多，但遇到特定场景，它就是最趁手的家伙。今天咱们就聊聊这个容易被忽视的 SQL 利器。
先说说 HAVING 到底在干嘛。简单理解，它就是 WHERE 的升级版，专门用来过滤分组之后的数据。WHERE 在分组之前筛选行，比如“找出所有年龄大于 30 岁的用户”；而 HAVING 在分组之后筛选组，比如“找出平均消费超过 500 元的用户群体”。一个典型的场景是：你想统计每个城市的订单量，但只关心订单量超过 1000 的城市。这时候，先 GROUP BY 城市，再 HAVING COUNT() > 1000，一步到位。很多新手容易犯的错是，试图在 WHERE 里用聚合函数，例如 WHERE COUNT() > 1000，这必定报错——因为 WHERE 执行时，分组还没发生。
那具体怎么用呢？语法其实很简单：举个例子，假设你有个销售表，想找出每个产品类别中总销售额超过 10 万的类别。代码大概长这样：你看，HAVING 后面直接跟聚合函数 SUM(amount) 的条件。那 WHERE 能干啥？WHERE 用来过滤单行数据，比如“只统计 2024 年的销售记录”，就得在 GROUP BY 之前写 。记住顺序：WHERE 先过滤行，再 GROUP BY 分组，最后 HAVING 过滤组。
新手最容易踩的坑是搞混 WHERE 和 HAVING 的作用域。我见过一个案例：有人想统计每个部门的平均工资，但只显示平均工资超过 8000 的部门。他写成结果数据库报错，他还一脸懵。正确写法是：记住口诀：WHERE 管行，HAVING 管组。如果条件里既涉及单行筛选又涉及组筛选，先用 WHERE 把不相关的行剔除，再用 HAVING 处理组条件。比如统计 2024 年入职员工的平均工资，只显示平均工资高于 7000 的部门：先 ，再 ，最后 。
再聊一个进阶用法：HAVING 可以和多种聚合函数搭配，不止 SUM 和 AVG。比如用 COUNT() 找出订单数超过 100 的客户，用 MAX(price) 筛选最高单价超过 5000 的商品类别，用 MIN(salary) 找到最低工资低于 3000 的部门。你甚至可以组合多个条件，例如 。这在实际业务中非常实用。比如电商平台想找出“月订单量超过 1000 且平均客单价高于 200 元”的店铺，或者 HR 想找出“员工数超过 20 人且平均工龄超过 5 年”的部门。HAVING 就像一个过滤器，帮你从一堆分组数据中捞出真正有价值的群体。
说到性能，HAVING 也有需要注意的地方。因为它在分组之后才执行过滤，如果分组数量特别大，性能可能受影响。举个例子，你有个千万级的订单表，按用户 ID 分组后可能有几十万个组，这时候 HAVING 要对每个组计算聚合值，压力不小。优化思路有两点：一是先用 WHERE 过滤掉大量无关行，减少分组的数据量；二是如果条件允许，把部分筛选逻辑移到 WHERE 里。比如想找“订单总额超过 10 万且 2024 年有交易”的客户，可以先 过滤出 2024 年的订单，再 ，最后 。这样分组的数据量会小很多，性能明显提升。
还有一点容易忽略：HAVING 后面不仅能跟聚合函数，也能跟非聚合列，但前提是该列必须出现在 GROUP BY 子句里。比如这在逻辑上等同于先用 过滤，再分组。但实际中，这种写法并不推荐——因为 WHERE 更符合直觉，对索引也更友好。不过，如果你用 进行模糊匹配，也不是错误，只是性能可能比 WHERE 差一些。我的建议是：能用 WHERE 解决的，就别用 HAVING；HAVING 只用来处理必须在分组之后才能判断的条件。
聊一个实战案例。之前帮一个做零售的朋友优化报表，他的需求是：统计每个门店中单价超过 100 元的商品的总销量，并且只显示总销量超过 500 件的门店。原始 SQL 是：这个写法本身没问题，但数据量大时跑得很慢。我建议先在 price 和 quantity 上建立索引，并把 WHERE 条件改得更精确——比如只筛选最近一年的数据。优化后，查询时间从 8 秒降到 0.3 秒。可以看到，HAVING 本身不是性能杀手，关键是配合合适的查询条件和索引。
总结一下：HAVING 是 SQL 里一个非常实用的工具，专门用来过滤分组数据。它和 WHERE 分工明确：WHERE 管行，HAVING 管组。使用时记住三点：第一，HAVING 后面只能跟聚合函数或 GROUP BY 里的列；第二，先用 WHERE 过滤行，减少分组压力；第三，性能敏感时，考虑索引和查询条件的优化。下次写 SQL 时遇到“按组筛选”的需求，别犹豫，直接用 HAVING。它就是你数据库工具箱里那把最趁手的梅花扳手——平时低调，用对了地方，能帮你省不少力气。
