引言
在SQL查询中，数据过滤是核心操作之一。我们常用WHERE子句进行行级过滤，但当需要对分组后的结果进行条件筛选时，HAVING关键字便成为不可或缺的工具。本文将深入探讨HAVING的作用、使用场景及其与WHERE的区别，并通过实际案例帮助开发者掌握这一关键语法。
1. HAVING是什么？
HAVING是SQL中用于对GROUP BY分组后的结果进行条件过滤的关键字。它允许我们基于聚合函数（如SUM、AVG、COUNT）或分组后的列值，筛选出符合条件的数据组。
核心特点：
分组后过滤：作用于
GROUP BY之后，处理的是“组”而非“行”。支持聚合函数：可直接在条件中使用
SUM()、AVG()等。灵活性：可引用
SELECT中的列别名。
2. 为什么需要HAVING？
假设你需要回答以下业务问题：
“哪些客户的订单总数超过100件？”
“哪个部门的平均工资高于公司整体平均？”
这些问题无法通过WHERE直接实现，因为过滤条件依赖于分组后的计算结果。
此时，HAVING是唯一的选择。
3. HAVING与WHERE的区别
执行顺序：
SQL查询的执行顺序为：
WHERE → GROUP BY → HAVING → ORDER BY → LIMIT
这意味着：
WHERE在分组前过滤原始数据，减少进入分组的数据量。HAVING在分组后过滤，决定哪些组保留在结果中。
功能对比：
| 特性 | WHERE | HAVING |
|---|---|---|
| 过滤对象 | 原始表的行 | 分组后的组 |
| 聚合函数 | 不可使用 | 必须使用 |
| 性能影响 | 优先使用，减少计算开销 | 在分组后处理，可能更耗时 |
| 别名支持 | 不支持SELECT中的别名 | 支持 |
4. HAVING的经典使用场景
场景1：筛选聚合结果
统计销售额超过1万元的商品类别：
SELECT category, SUM(price) AS total_sales
FROM products
GROUP BY category
HAVING total_sales > 10000; -- 直接使用别名场景2：多层条件组合
查询平均分高于80且不及格次数少于3次的学生：
SELECT student_id,
AVG(score) AS avg_score,
COUNT(CASE WHEN score < 60 THEN 1 END) AS fail_count
FROM exam_results
GROUP BY student_id
HAVING avg_score >= 80 AND fail_count < 3;场景3：无GROUP BY的HAVING
将整个表视为一个组，筛选总记录数：
SELECT COUNT(*) AS total_users
FROM users
HAVING total_users > 1000; -- 类似于WHERE，但允许使用聚合5. 实战案例：电商数据分析
需求：找出2023年订单金额超过5万元且退货率低于5%的客户。
SELECT
customer_id,
SUM(order_amount) AS total_spent,
COUNT(order_id) AS total_orders,
SUM(CASE WHEN is_returned = 1 THEN 1 ELSE 0 END) AS return_count,
(return_count / total_orders) * 100 AS return_rate
FROM orders
WHERE YEAR(order_date) = 2023 -- 先过滤2023年数据
GROUP BY customer_id
HAVING
total_spent > 50000
AND return_rate < 5;解析：
WHERE先过滤掉非2023年的订单，减少后续计算量。GROUP BY按客户分组，计算总消费、订单数、退货数。HAVING筛选出高消费、低退货率的优质客户。
6. 常见错误与避坑指南
错误1：在WHERE中使用聚合函数
-- 错误！WHERE不能处理聚合函数
SELECT department, AVG(salary)
FROM employees
WHERE AVG(salary) > 10000 报错信息：Invalid use of group function
错误2：混淆过滤顺序
-- 错误逻辑：先按部门分组，再筛选工资>10000的人，导致结果不准确
SELECT department, AVG(salary)
FROM employees
GROUP BY department
HAVING salary > 10000; -- 这里salary已不表示原始行数据！修正：应在WHERE中提前过滤个体数据，再分组计算。
7. 性能优化建议
优先使用WHERE：尽可能在分组前用
WHERE减少数据量。
-- 优化前（性能差）
SELECT user_id, COUNT(*)
FROM logs
GROUP BY user_id
HAVING COUNT(*) > 100 AND created_at > '2023-01-01';
-- 优化后（先过滤时间）
SELECT user_id, COUNT(*)
FROM logs
WHERE created_at > '2023-01-01'
GROUP BY user_id
HAVING COUNT(*) > 100;2.避免复杂HAVING条件：复杂的计算尽量在SELECT中预先定义。
-- 不推荐
HAVING (SUM(income) - SUM(cost)) > 1000;
-- 推荐
SELECT ..., (SUM(income) - SUM(cost)) AS profit
GROUP BY ...
HAVING profit > 1000;8. 高级技巧
技巧1：HAVING与CASE结合
动态标记数据组：
SELECT
product_category,
AVG(price) AS avg_price,
CASE
WHEN AVG(price) > 100 THEN 'High'
ELSE 'Low'
END AS price_level
FROM products
GROUP BY product_category
HAVING price_level = 'High'; -- 使用CASE生成的别名技巧2：与窗口函数结合（MySQL 8.0+）
筛选排名前3的销售员：
SELECT *
FROM (
SELECT
salesperson_id,
SUM(amount) AS total_sales,
RANK() OVER (ORDER BY SUM(amount) DESC) AS sales_rank
FROM sales
GROUP BY salesperson_id
) AS ranked_sales
WHERE sales_rank <= 3; -- 注意：此处仍可用WHERE，因为窗口函数在HAVING后执行9. 总结
HAVING是处理分组后过滤的终极武器，尤其在数据分析场景中不可或缺。记住以下关键点：
执行顺序：
WHERE→GROUP BY→HAVING。聚合依赖：条件涉及
SUM、AVG等时必用HAVING。性能优先：尽量用
WHERE提前过滤，减少分组计算量。
掌握HAVING的使用，将显著提升你处理复杂分组查询的能力。现在，尝试在你的下一个SQL查询中实践它吧！
动手练习：
在熟悉的数据库中创建一个销售表，尝试用HAVING解决以下问题：
找出月度销售额连续3个月超过10万的店铺。
统计活跃用户（过去30天登录≥5次）。
欢迎在评论区分享你的解决方案！ 🚀