HAVING子句用于对分组后的聚合结果进行筛选，而WHERE则在分组前过滤原始行。执行顺序为：先WHERE过滤，再GROUP BY分组，最后HAVING筛选满足聚合条件的分组。例如，SELECT department_id, SUM(sales_amount) FROM sales_data WHERE transaction_date >= ‘2023-01-01’ GROUP BY department_id HAVING SUM(sales_amount) > 100000；此查询先通过WHERE筛选2023年后的交易记录，再按部门分组，最后用HAVING找出总销售额超10万的部门。关键区别在于作用时机与对象：WHERE作用于行，不能使用聚合函数；HAVING作用于分组，可直接引用COUNT、SUM、AVG等聚合结果。当需同时基于行条件和组级条件过滤时，两者可结合使用。在HAVING中引用非聚合列时，该列必须出现在GROUP BY中，否则会引发错误。对于复杂筛选，如比较分组结果与全局均值，可通过子查询或CTE实现，如用WITH DepartmentSales AS (…) , OverallAverage AS (…) 构建中间结果，使逻辑更清晰。CTE不仅提升可读性，还支持多层分析，扩展HAVING的应用场景。根据您的要求，以下是符合所有规则的摘要：答案：HAVING在GROUP BY后对

SQL聚合函数与HAVING条件结合使用，其核心在于对已经通过

GROUP BY

子句分组后的数据进行筛选。简单来说，

WHERE

子句是在数据分组之前对原始行进行过滤，而

HAVING

子句则是在数据分组之后，对每个分组的聚合结果进行条件判断。这就像我们先按照某种标准把人群分成几个小组，然后

WHERE

是在分小组前就把不符合条件的人剔除，而

HAVING

则是在小组分好后，再根据每个小组的整体表现（比如平均分、总人数）来决定哪些小组符合要求。

解决方案

要将SQL聚合函数与HAVING条件结合使用，你首先需要理解其背后的逻辑流程：数据从表中被选取出来，然后经过

WHERE

子句的初步筛选，接着被

GROUP BY

子句按照指定的列进行分组。最后，

HAVING

子句出场，它会检查每个分组的聚合结果（如

COUNT()

,

SUM()

,

AVG()

,

MAX()

,

MIN()

等），只有满足条件的那些分组才会被最终的

SELECT

语句返回。

一个典型的使用场景是，你可能想找出那些销售额超过一定数额的部门，或者参与人数多于某个阈值的项目。

SELECT     department_id,     SUM(sales_amount) AS total_sales,     COUNT(employee_id) AS employee_count FROM     sales_data WHERE     transaction_date >= '2023-01-01' -- 这是一个WHERE条件，先过滤2023年1月1日之后的交易 GROUP BY     department_id HAVING     SUM(sales_amount) > 100000 -- 筛选总销售额超过10万的部门     AND COUNT(employee_id) > 5; -- 并且该部门员工数超过5个

在这个例子中，

sales_data

表首先会根据

transaction_date

进行初步过滤，只保留2023年以来的交易记录。接着，这些过滤后的记录会按照

department_id

进行分组。最后，

HAVING

子句会对每个部门（即每个分组）的总销售额和员工数量进行检查，只有那些总销售额大于100000且员工数大于5的部门，才会被最终显示出来。

HAVING 与 WHERE 有何本质区别，以及何时选择它们？

这真的是一个非常常见的问题，也是我在刚接触SQL时最容易混淆的地方。我的经验是，理解它们执行的“时机”是关键。

WHERE

子句在数据被

GROUP BY

分组之前执行，它作用于单个行。你可以把它想象成一道门槛，在数据进入分组区域前，不符合条件的个体（行）就被拦在外面了。所以，

WHERE

不能直接引用聚合函数的结果，因为它在聚合函数计算之前就已经完成了筛选。

-- 错误示例：WHERE中不能直接使用聚合函数 SELECT department_id, SUM(sales_amount) FROM sales_data WHERE SUM(sales_amount) > 100000 -- 错误！ GROUP BY department_id;

而

HAVING

子句则在

GROUP BY

分组之后执行，它作用于整个分组。它就像分组完成后的一个裁判，根据每个分组的“整体表现”（聚合结果）来决定哪些分组可以晋级。因此，

HAVING

可以且通常会引用聚合函数。

何时选择它们？

• 选择

  WHERE

  ： 当你需要基于原始表的列值来过滤单个行时。比如，你只想分析某个特定日期范围内的交易，或者某个特定客户的订单。

  WHERE

  会减少进入

  GROUP BY

  的数据量，这通常会提升查询性能。

• 选择

  HAVING

  ： 当你需要基于聚合函数的结果来过滤分组时。比如，你只想看那些平均销售额高于某个值的地区，或者订单数量少于某个阈值的供应商。

有时候，你甚至会发现它们可以同时存在，就像我上面给出的解决方案一样。先用

WHERE

缩小原始数据范围，再用

HAVING

筛选聚合结果，这是非常高效且常见的做法。

如何在 HAVING 条件中引用多个聚合函数或非聚合列？

在

HAVING

条件中引用多个聚合函数是非常直接的，你可以像在

WHERE

子句中使用

AND

、

OR

等逻辑运算符一样，将多个条件组合起来。这允许你对分组的聚合结果进行更复杂的筛选。

SELECT     product_category,     COUNT(order_id) AS total_orders,     AVG(order_total) AS average_order_value,     SUM(quantity) AS total_quantity_sold FROM     order_items WHERE     order_date BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY     product_category HAVING     COUNT(order_id) > 50 -- 订单总数超过50     AND AVG(order_total) > 200 -- 平均订单价值超过200     OR SUM(quantity) > 1000; -- 或者总销售数量超过1000

这个例子展示了如何使用

AND

和

OR

来组合多个聚合条件。它会找出那些在2023年，订单总数超过50且平均订单价值超过200的产品类别，或者总销售数量超过1000的产品类别。

至于在

HAVING

中引用非聚合列，这需要一些额外的思考。

HAVING

条件中引用的非聚合列必须出现在

GROUP BY

子句中。这是因为

HAVING

是在分组之后对每个分组进行判断，如果一个列没有被用于分组，那么在分组的上下文中，它的值是不确定的（一个分组可能包含该列的多个不同值）。

Kira

AI创意图像生成与编辑平台

58

查看详情

-- 示例：在HAVING中引用非聚合列（但该列必须在GROUP BY中） SELECT     region,     city, -- city 是非聚合列，但它在GROUP BY中     COUNT(customer_id) AS customer_count FROM     customers GROUP BY     region, city HAVING     COUNT(customer_id) > 100     AND region = 'North'; -- region是分组列，可以在HAVING中直接使用

如果

city

没有在

GROUP BY

中，而你尝试在

HAVING

中使用

city = 'New York'

，那么SQL引擎会报错，因为它不知道哪个

city

值代表整个分组。所以，牢记这一点，可以避免很多不必要的错误。

结合子查询或 CTE，HAVING 能实现哪些高级筛选？

当简单的

HAVING

条件不足以满足你的需求时，结合子查询（Subquery）或公共表表达式（CTE – Common Table Expression）能让

HAVING

的筛选能力变得异常强大。这通常发生在你需要基于一个复杂计算的结果来过滤分组，或者需要比较一个分组的聚合结果与整个数据集的某个聚合结果时。

示例1：HAVING 结合子查询，筛选出高于平均水平的分组

假设我们想找出那些销售额高于所有部门平均销售额的部门。直接在

HAVING

中使用

AVG(SUM(sales_amount))

是不行的，因为

AVG()

不能直接作用于另一个聚合函数的结果。这里就需要子查询了。

SELECT     department_id,     SUM(sales_amount) AS total_department_sales FROM     sales_data GROUP BY     department_id HAVING     SUM(sales_amount) > (SELECT AVG(total_sales) FROM (SELECT SUM(sales_amount) AS total_sales FROM sales_data GROUP BY department_id) AS department_summary);

这个查询有点绕，我们先用一个子查询计算出每个部门的总销售额，然后在这个结果集上再计算所有部门的平均销售额。最后，

HAVING

子句将每个部门的总销售额与这个全局平均值进行比较。

示例2：HAVING 结合 CTE，实现更清晰的复杂筛选

使用CTE可以让复杂的查询逻辑变得更易读和管理。我们用CTE重写上面的例子。

WITH DepartmentSales AS (     SELECT         department_id,         SUM(sales_amount) AS total_sales     FROM         sales_data     GROUP BY         department_id ), OverallAverage AS (     SELECT         AVG(total_sales) AS avg_sales_across_departments     FROM         DepartmentSales ) SELECT     ds.department_id,     ds.total_sales FROM     DepartmentSales ds WHERE     ds.total_sales > (SELECT avg_sales_across_departments FROM OverallAverage);

这里，我故意将

HAVING

替换成了

WHERE

，因为在CTE处理后，

total_sales

已经是一个具体的列值，不再是聚合结果，所以可以直接用

WHERE

。这其实也反映了一个重要的思想：当你把聚合结果通过子查询或CTE“固化”为一个新的数据集时，后续的筛选就可以回归到

WHERE

子句的范畴。

当然，如果你坚持要在最终的

SELECT

块中使用

HAVING

，并且条件仍然是基于新的聚合，那是可以的。但在这个特定场景下，

WHERE

更自然。

高级筛选通常涉及到多层逻辑，子查询和CTE提供了一种将这些逻辑分解、逐步实现的方式，让

HAVING

能够处理更复杂的业务规则。我的建议是，当查询变得复杂时，优先考虑CTE，它能让你的SQL代码像写程序一样，一步步构建，可读性大大提升。