having子句用于过滤分组后的数据，与where在分组前过滤行不同，having在group by之后执行，可基于聚合函数如count、sum、avg等条件筛选组；1. where作用于分组前的行，不能使用聚合函数；2. having作用于分组后的组，可使用聚合函数；3. 执行顺序为from → where → group by → having → select → order by；4. 常见应用场景包括筛选活跃客户、识别低访问时长页面、计算好评率等；5. 性能优化建议：先用where减少数据量，避免having处理过多分组，复杂逻辑可用cte分解，注意聚合函数开销和索引无法直接用于having条件。因此，正确区分where与having的使用时机，能显著提升查询效率与准确性。
在sql里，当你需要对已经分组的数据进行二次筛选时，
HAVING
子句就是你的得力助手。它不像
WHERE
那样在数据分组前就动手，而是专为
GROUP BY
之后的结果集服务，能让你基于聚合函数（比如
COUNT
,
SUM
,
AVG
等）的计算结果来设定过滤条件。简单来说，
HAVING
就是用来过滤“组”的。
要使用
HAVING
子句过滤分组后的结果，核心在于理解其执行顺序：它总是在
GROUP BY
之后才发挥作用。这意味着你可以直接在
HAVING
条件中使用聚合函数。
一个典型的场景是，你可能想找出那些销售总额超过某个阈值的客户，或者订单数量少于特定数值的产品类别。
-- 假设我们有一个销售表 (Sales)，包含产品ID (product_id) 和销售额 (amount) -- 目标：找出总销售额超过10000的产品类别 SELECT product_id, SUM(amount) AS total_sales FROM Sales GROUP BY product_id HAVING SUM(amount) > 10000; -- 另一个例子：找出订单数量少于5的客户 -- 假设有 Orders 表，包含 customer_id 和 order_id SELECT customer_id, COUNT(order_id) AS order_count FROM Orders GROUP BY customer_id HAVING COUNT(order_id) < 5;
你先用
GROUP BY
把数据按你需要的维度（比如
product_id
或
customer_id
）聚合起来，然后
HAVING
就登场了，它会检查每个分组的聚合结果是否满足你设定的条件。这和
WHERE
根本不是一回事，
WHERE
是在数据还没被分组、还没被聚合的时候就进行行的过滤。
HAVING 与 WHERE 子句有何不同？何时该用哪个？
这是一个我经常被问到的问题，也是很多SQL初学者容易混淆的地方。
WHERE
和
HAVING
看起来都是用来过滤的，但它们作用的时机和对象截然不同。
WHERE
子句，它是在数据被
GROUP BY
聚合之前对原始行进行筛选。你可以把它想象成一道预检关卡，只有通过了
WHERE
条件的行，才有资格进入后续的聚合计算。所以，你在
WHERE
里不能直接使用聚合函数，因为它作用时聚合还没发生呢。比如，你想筛选出某个日期之后的所有销售记录，那就是
WHERE sales_date > '2023-01-01'
。
而
HAVING
子句呢，它是在数据经过
GROUP BY
聚合之后，对已经形成的“组”进行筛选。它看的是每个组的整体属性，比如这个组的总和、平均值、计数等等。因此，
HAVING
里能够，也通常会使用聚合函数。比如，你已经按产品ID分好组了，现在想看看哪些产品的总销售额超过了1000，这时
HAVING SUM(amount) > 1000
就派上用场了。
简单来说，如果你想过滤“行”，用
WHERE
；如果你想过滤“组”，用
HAVING
。如果一个查询既有行过滤需求，又有组过滤需求，那么通常的顺序是
FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY
。记住这个顺序，能帮你理清思路，少走弯路。
在实际业务场景中，HAVING 子句有哪些常见应用案例？
在我日常接触的数据分析任务中，
HAVING
子句简直是解决某些特定问题的利器。它能帮我们从宏观层面筛选出我们真正关心的群体，而不是纠结于每一条细枝末节的记录。
一个很经典的例子就是找出“活跃”或“非活跃”的群体。比如，我想看看哪些客户在过去一年里至少下了5个订单。我不会去逐条检查每个订单，而是会按
customer_id
分组，然后用
HAVING COUNT(order_id) >= 5
来筛选。这一下子就把符合条件的客户列表给揪出来了。
再比如，识别异常值或趋势。假设你负责监控网站的流量，你想找出那些平均访问时长低于某个阈值（比如30秒）的页面，这可能意味着用户对这些内容不感兴趣。你就可以
GROUP BY page_id
，然后
HAVING AVG(session_duration) < 30
。这比你一条条看访问日志有效率多了。
还有，基于比例或百分比进行筛选。虽然
HAVING
直接处理聚合值，但你也可以在聚合函数内部或外部进行一些数学运算来达到比例筛选的目的。例如，在一个产品评论系统中，你可能想找出那些“好评率”低于80%的产品，虽然这可能需要稍微复杂的聚合表达式，但
HAVING
依然是最终筛选分组的关键。
这些例子都说明，
HAVING
让我们能站在更高维度去审视数据，从“点”的筛选跃升到“面”的筛选，这对于业务决策来说，往往更有价值。
使用 HAVING 子句时，有哪些性能考量和潜在的“坑”？
说实话，
HAVING
虽然好用，但在实际应用中，如果不多加注意，也可能踩到一些“坑”，尤其是在处理大量数据时，性能问题会变得很突出。
最大的一个考量点就是执行顺序与数据量。前面提到，
HAVING
是在
GROUP BY
之后才执行的。这意味着，如果你的
GROUP BY
操作本身就处理了海量数据，那么即使
HAVING
最终过滤掉了大部分组，聚合计算的过程依然会消耗大量资源。所以，如果可能的话，尽量先用
WHERE
过滤掉不必要的原始数据行，减少
GROUP BY
的输入，这样
HAVING
的工作量也会随之减轻。比如，如果你只需要分析2023年的数据，先
WHERE year = 2023
，再
GROUP BY
和
HAVING
，效率会高很多。
另一个常见的“坑”是误用索引。
HAVING
子句通常无法直接利用为原始列建立的索引，因为它操作的是聚合后的结果。这意味着数据库可能需要进行全表扫描或大量的临时表操作来完成聚合，然后再进行
HAVING
过滤。虽然现代数据库优化器很智能，但在某些复杂查询中，你可能需要考虑是否可以通过预聚合或物化视图来优化性能。
再就是聚合函数的复杂性。如果你在
HAVING
子句中使用了非常复杂的聚合函数，或者嵌套了子查询，这无疑会增加计算负担。有时候，将复杂的
HAVING
条件拆解成多个步骤，或者利用 CTE (Common table Expressions) 来清晰化逻辑，不仅有助于理解，也可能让优化器有更好的发挥空间。
总的来说，用
HAVING
时，脑子里要有个“大局观”：它是在聚合之后才过滤，所以能提前通过
WHERE
减少数据量是王道。别指望它能帮你直接利用原始列的索引，它看的是聚合的“果”，而不是原始的“因”。
