HAVING用于筛选分组后的聚合结果，WHERE用于过滤分组前的原始行数据；执行顺序上WHERE先于GROUP BY，HAVING在GROUP BY之后，二者可结合使用以提升查询效率。
HAVING子句在SQL中，是专门用来筛选经过
GROUP BY分组后的数据。它与
WHERE子句不同，
WHERE在数据分组之前对单行记录进行筛选，而
HAVING则是在聚合函数（如
COUNT(),
SUM(),
AVG(),
MAX(),
MIN()）计算出结果之后，再对这些聚合结果进行条件过滤。简单来说，如果你想基于某个总和、平均值或数量来筛选组，那就用
HAVING。
解决方案
使用
HAVING结合聚合函数筛选数据，其核心在于理解SQL查询的执行顺序。它总是在
GROUP BY之后执行。基本语法结构是这样的：
SELECT
column1,
aggregate_function(column2)
FROM
table_name
GROUP BY
column1
HAVING
aggregate_function(column2) [comparison_operator] value;举个例子，假设我们有一个
orders表，里面有
customer_id和
amount字段。我们想找出那些总订单金额超过1000的客户。
SELECT
customer_id,
SUM(amount) AS total_spent
FROM
orders
GROUP BY
customer_id
HAVING
SUM(amount) > 1000;这里，
SUM(amount)是一个聚合函数，它计算了每个客户的总金额。
HAVING SUM(amount) > 1000则是在这些总金额计算出来之后，筛选出那些总金额大于1000的客户。如果没有
HAVING，我们是无法直接在
WHERE子句中使用
SUM(amount)的，因为
WHERE是在行级别操作的。
HAVING与WHERE子句有何本质区别？何时选用它们？
这真的是SQL初学者，甚至是一些有经验的开发者都会偶尔混淆的点。我个人觉得，理解它们的执行时机是关键。
WHERE子句，它就像是数据进入厨房前的第一道关卡，负责对每一份食材（每一行数据）进行检查，不符合条件的直接剔除，连锅都不让进。它作用于原始的、未聚合的行数据。所以，你不能在
WHERE里直接用
COUNT()、
SUM()这类聚合函数，因为那时候数据还没“聚”起来。
而
HAVING呢，它更像是菜肴出锅前的最后一道品控。当所有食材都经过烹饪（
GROUP BY分组和聚合函数计算）变成了最终的菜品（聚合结果）后，
HAVING才开始工作，检查这些“菜品”是否符合标准。比如，你做了一桌菜，
HAVING会说：“这盘菜如果总重量小于500克，就不能上桌！”它看的是整体，是聚合后的结果。
什么时候用哪个？
-
用
WHERE
： 当你需要基于原始行数据进行筛选时。比如，只统计“活跃”用户的订单，或者只考虑“2023年”的销售数据。这些条件都不依赖于聚合结果。-- 找出2023年单笔订单金额超过100的所有订单 SELECT order_id, customer_id, amount FROM orders WHERE order_date BETWEEN '2023-01-01' AND '2023-12-31' AND amount > 100;
-
用
HAVING
： 当你的筛选条件依赖于聚合函数的结果时。比如，找出平均销售额超过某个数值的地区，或者至少有5个订单的客户。-- 找出平均订单金额超过200的客户 SELECT customer_id, AVG(amount) AS avg_order_amount FROM orders GROUP BY customer_id HAVING AVG(amount) > 200;
有时候，两者甚至会一起出现。比如，我们想找出2023年那些总订单金额超过1000的客户。这时，先用
WHERE筛选出2023年的订单，再用
GROUP BY和
HAVING来聚合和筛选。
SELECT
customer_id,
SUM(amount) AS total_spent
FROM
orders
WHERE
order_date BETWEEN '2023-01-01' AND '2023-12-31' -- 先筛选2023年的订单
GROUP BY
customer_id
HAVING
SUM(amount) > 1000; -- 再筛选总金额大于1000的客户这种组合使用非常常见，也是写出高效且精确SQL的关键。
结合多个聚合函数或条件在HAVING中进行筛选的实际场景
HAVING子句的强大之处在于，它不仅限于一个简单的聚合条件。你可以像在
WHERE子句中那样，使用
AND、
OR、
NOT等逻辑运算符来组合多个聚合条件，甚至结合多个不同的聚合函数进行筛选。这在处理复杂的业务逻辑时显得尤为有用。
想象一个场景：我们想找出那些平均订单金额超过500，并且总订单数至少有3个的客户。
SELECT
customer_id,
AVG(amount) AS avg_order_amount,
COUNT(order_id) AS total_orders
FROM
orders
GROUP BY
customer_id
HAVING
AVG(amount) > 500 AND COUNT(order_id) >= 3;在这个例子中，我们同时使用了
AVG()和
COUNT()这两个聚合函数，并在
HAVING子句中用
AND将它们的条件连接起来。只有同时满足这两个条件的客户才会被返回。
再来一个稍微复杂点的：找出那些总销售额超过10000，或者虽然总销售额没到10000但至少有100笔交易的商品。
SELECT
product_id,
SUM(sale_amount) AS total_sales,
COUNT(transaction_id) AS total_transactions
FROM
sales_records
GROUP BY
product_id
HAVING
SUM(sale_amount) > 10000 OR COUNT(transaction_id) >= 100;这种灵活性让
HAVING成为处理报表和数据分析中“基于汇总数据进行筛选”任务的利器。你可能会发现，很多时候业务部门提的需求，最终落实到SQL上，都需要
HAVING来完成这种多维度、基于聚合结果的筛选。
在SQL查询优化中，HAVING的使用有哪些值得注意的地方？
谈到优化，
HAVING的使用确实有一些值得我们思考的地方。我经常会看到一些查询，明明可以在
WHERE子句中完成的筛选，却被放到了
HAVING里。虽然结果可能一样，但性能上却可能大相径庭。
核心原则是：能用WHERE
的，就不要用HAVING
。
为什么这么说？因为
WHERE子句在数据分组和聚合之前就对数据进行了过滤。这意味着它减少了需要处理的行数，从而减轻了
GROUP BY和聚合函数的工作量。如果你的原始数据集非常庞大，先用
WHERE过滤掉大量不相关的行，那么后续的聚合操作就会快很多。
举个例子：我们只想分析2023年的数据，并且找出总金额超过1000的客户。
低效的做法（尽量避免，如果条件可以下推到WHERE）：
SELECT
customer_id,
SUM(amount) AS total_spent
FROM
orders
GROUP BY
customer_id
HAVING
SUM(amount) > 1000
AND MAX(order_date) >= '2023-01-01' -- 这里尝试用HAVING过滤年份，但效率不如WHERE
AND MIN(order_date) <= '2023-12-31';这里，
MAX(order_date)和
MIN(order_date)是聚合函数，所以它们必须在
HAVING里。但如果目的只是筛选2023年的订单，那么在
WHERE里直接过滤
order_date列会更高效。
高效的做法：
SELECT
customer_id,
SUM(amount) AS total_spent
FROM
orders
WHERE
order_date BETWEEN '2023-01-01' AND '2023-12-31' -- 先在WHERE过滤年份
GROUP BY
customer_id
HAVING
SUM(amount) > 1000; -- 再在HAVING过滤聚合结果在这个高效的例子中，数据库引擎首先会根据
WHERE子句过滤掉所有非2023年的订单，这样
GROUP BY和
SUM()只需要处理2023年的数据，大大减少了计算量。
当然，有些时候你别无选择，条件本身就依赖于聚合结果，那就必须使用
HAVING。这时候，我们能做的就是确保
GROUP BY的列上建有合适的索引，这有助于加速分组过程。
总的来说，
HAVING是SQL中一个非常强大且不可或缺的工具，但理解其在查询生命周期中的位置，并结合
WHERE子句进行合理的划分，是写出高效、可维护SQL查询的关键一步。
