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_countFROM sales_dataWHERE transaction_date >= '2023-01-01' -- 这是一个WHERE条件，先过滤2023年1月1日之后的交易GROUP BY department_idHAVING 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_dataWHERE 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_soldFROM order_itemsWHERE order_date BETWEEN '2023-01-01' AND '2023-12-31'GROUP BY product_categoryHAVING 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
是在分组之后对每个分组进行判断，如果一个列没有被用于分组，那么在分组的上下文中，它的值是不确定的（一个分组可能包含该列的多个不同值）。
Zend Framework 2.4.3 完整版本
Zend框架2是一个开源框架,使用PHP 5.3 +开发web应用程序和服务。Zend框架2使用100%面向对象代码和利用大多数PHP 5.3的新特性,即名称空间、延迟静态绑定,lambda函数和闭包。Zend框架2的组成结构是独一无二的;每个组件被设计与其他部件数的依赖关系。 ZF2遵循SOLID面向对象的设计原则。 这样的松耦合结构可以让开发人员使用他们想要的任何部件。我们称之为“松耦合”
344 查看详情 
-- 示例：在HAVING中引用非聚合列（但该列必须在GROUP BY中）SELECT region, city, -- city 是非聚合列，但它在GROUP BY中 COUNT(customer_id) AS customer_countFROM customersGROUP BY region, cityHAVING 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_salesFROM sales_dataGROUP BY department_idHAVING 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_salesFROM DepartmentSales dsWHERE 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代码像写程序一样，一步步构建，可读性大大提升。
以上就是SQL 聚合函数如何结合 HAVING 条件使用？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/959391.html
微信扫一扫 
支付宝扫一扫 
![Go语言接口与切片：如何识别和操作[]interface{}](https://cdn.chuangxiangniao.com/www/2025/12/176369856569294-1.jpg?imageMogr2/crop/480x300/gravity/center)
