HAVING用于过滤分组后的聚合结果，而WHERE作用于分组前的原始行数据；应先用WHERE减少数据量，再用HAVING筛选满足聚合条件的组，两者结合可提升查询效率。
在SQL里，HAVING子句是用来对GROUP BY分组后的结果进行过滤的。简单来说，它就像WHERE子句，但WHERE是作用于原始的行数据，而HAVING则是作用于那些已经被聚合（比如求和、平均、计数）后的组数据。如果你想基于某个聚合值来筛选分组，那就非HAVING莫属了。
解决方案
HAVING子句的魅力在于它能让我们在数据聚合之后，还能再进行一层精细的筛选。想象一下，你已经把所有员工按部门分好组，并且计算出了每个部门的平均工资，现在你想找出那些平均工资超过某个阈值的部门，这时候HAVING就派上用场了。
它的基本语法结构通常是这样的：
SELECT
column1,
aggregate_function(column2)
FROM
table_name
WHERE
condition -- (可选) 在分组前过滤行
GROUP BY
column1 -- 对数据进行分组
HAVING
aggregate_condition -- 在分组后过滤组
ORDER BY
column1; -- (可选) 对最终结果排序这里有个具体的例子，假设我们有个Employees表，里面有Department（部门）和Salary（薪水）字段。我想找出那些平均薪水超过50000的部门：
SELECT
Department,
AVG(Salary) AS AverageSalary
FROM
Employees
GROUP BY
Department
HAVING
AVG(Salary) > 50000;这段代码的执行流程是：
- 从
Employees表里获取数据。 - 根据
Department字段把员工分成不同的组。 - 对每个部门组，计算其
Salary的平均值。 - 然后，
HAVING子句开始工作，它会检查每个部门的AverageSalary是否大于50000。 - 只有那些满足条件的部门（以及它们的平均薪水）才会被最终显示出来。
在我看来，很多初学者，包括我自己在刚开始接触SQL时，最容易混淆的就是WHERE和HAVING。记住，WHERE处理的是原始行，它不关心聚合函数；而HAVING处理的是聚合后的组，它离不开聚合函数。如果你试图在WHERE里用AVG()，数据库会报错的。
HAVING与WHERE子句的主要区别是什么？它们何时应该被使用？
这是个老生常谈但又极其关键的问题，也是我发现很多人在写复杂查询时经常会踩坑的地方。理解它们之间的区别，不仅能让你写出正确的SQL，还能写出高效的SQL。
主要区别：
-
作用时机：
-
WHERE：在数据被GROUP BY分组和任何聚合计算之前，对单行数据进行过滤。它就像一个预筛选器。 -
HAVING：在数据已经通过GROUP BY分组，并且聚合函数（如SUM(),AVG(),COUNT(),MAX(),MIN()等）已经计算完毕之后，对分组后的结果（即组）进行过滤。
-
-
可使用条件：
-
WHERE：只能使用非聚合列的条件。你不能在WHERE子句中直接使用聚合函数。 -
HAVING：必须使用聚合函数作为条件，或者至少是聚合后的结果。因为它要基于组的特性来过滤。
-
执行顺序： SQL查询的逻辑执行顺序大致是这样的：
FROM->WHERE->GROUP BY->HAVING->SELECT->ORDER BY。这个顺序很重要，它解释了为什么WHERE在GROUP BY之前，而HAVING在GROUP BY之后。
何时使用：
-
使用
WHERE： 当你需要根据原始数据行中的条件来排除数据时。比如，你只关心某个特定部门的员工，或者某个日期范围内的订单。这能大大减少后续GROUP BY需要处理的数据量，从而提高查询效率。-- 找出薪水高于60000的员工，然后按部门分组 SELECT Department, COUNT(EmployeeID) AS NumberOfEmployees FROM Employees WHERE Salary > 60000 -- 在分组前，先过滤掉薪水不达标的员工 GROUP BY Department; -
使用
HAVING： 当你需要根据聚合函数的结果来筛选分组时。比如，你想找出员工数量超过5个的部门，或者平均订单金额高于1000元的客户。-- 找出员工数量超过5个的部门 SELECT Department, COUNT(EmployeeID) AS NumberOfEmployees FROM Employees GROUP BY Department HAVING COUNT(EmployeeID) > 5; -- 在分组后，根据员工数量过滤部门 -
两者结合使用： 很多时候，我们会同时用到
WHERE和HAVING。先用WHERE过滤掉不需要的原始行，再用HAVING过滤掉不符合聚合条件的组。这是最常见的场景，也是最高效的做法。-- 找出2022年之后入职，且平均薪水高于70000的部门 SELECT Department, AVG(Salary) AS AverageSalary FROM Employees WHERE HireDate >= '2022-01-01' -- 先过滤掉2022年之前入职的员工 GROUP BY Department HAVING AVG(Salary) > 70000; -- 再过滤平均薪资高于70000的部门这里，
WHERE子句首先减少了需要聚合的数据量，这对于大型数据集来说，性能提升是显而易见的。
在HAVING子句中使用多个条件或复杂逻辑时有哪些技巧？
在实际工作中，我们很少会遇到只需要一个简单HAVING条件的情况。通常，业务需求会更复杂，需要我们组合多个条件或使用更复杂的逻辑。幸运的是，HAVING子句和WHERE子句一样，支持标准的逻辑运算符。
-
使用
AND,OR,NOT组合条件： 这是最基本的技巧。你可以像在WHERE子句中那样，用AND、OR、NOT来连接多个聚合条件。-- 找出平均薪水高于60000，并且员工数量大于5的部门 SELECT Department, AVG(Salary) AS AvgSal, COUNT(EmployeeID) AS EmpCount FROM Employees GROUP BY Department HAVING AVG(Salary) > 60000 AND COUNT(EmployeeID) > 5;或者，如果你想找平均薪水特别高，或者员工数量特别多的部门：
-- 找出平均薪水高于80000 或 员工数量超过20的部门 SELECT Department, AVG(Salary) AS AvgSal, COUNT(EmployeeID) AS EmpCount FROM Employees GROUP BY Department HAVING AVG(Salary) > 80000 OR COUNT(EmployeeID) > 20; -
在
HAVING中使用SELECT列表中的别名（需注意方言差异）： 在某些数据库系统（比如MySQL）中，你可以在HAVING子句中直接使用在SELECT列表中为聚合函数定义的别名。这能让查询看起来更简洁、更易读。-- 假设是MySQL，使用别名 SELECT Department, AVG(Salary) AS AvgSal, COUNT(EmployeeID) AS EmpCount FROM Employees GROUP BY Department HAVING AvgSal > 60000 AND EmpCount > 5; -- 直接使用AvgSal和EmpCount但是，需要注意的是，这并非SQL标准，也不是所有数据库都支持。例如，SQL Server和PostgreSQL通常不允许在
HAVING中直接使用SELECT列表中的别名，你可能需要重复聚合函数。为了代码的可移植性，我个人倾向于在HAVING中重复聚合函数，虽然写起来略显冗长，但能保证在不同数据库上都能正常运行。 利用子查询（谨慎使用）： 虽然不常见，但在极少数复杂的场景下，
HAVING子句中也可以包含子查询。但这通常会使查询变得非常复杂，而且性能可能会受到影响。如果子查询能通过WHERE子句或者JOIN操作进行优化，那通常是更好的选择。一个例子可能是，你想找出那些平均销售额高于所有产品平均销售额的部门，这可能涉及一个子查询来计算整体平均销售额。不过，在我日常工作中，我更倾向于用CTE（Common Table Expressions，公共表表达式）来分解这种复杂逻辑，让查询结构更清晰。清晰的逻辑结构： 当条件很多时，使用括号来明确逻辑优先级非常重要，避免因为运算符优先级问题导致意想不到的结果。这和写任何编程语言的条件语句都一样。
总的来说，HAVING的复杂逻辑处理能力很强，但我们应该追求清晰和效率。过度复杂的HAVING条件，有时候暗示着查询设计上可能还有优化空间，比如是否能将部分过滤前置到WHERE，或者分解成多个步骤。
如何优化包含HAVING子句的SQL查询性能？
性能优化是SQL查询永恒的话题，对于包含HAVING子句的查询也不例外。我发现，很多时候性能瓶颈并不直接在HAVING本身，而是其前面的步骤。
-
WHERE子句的优先原则： 这是最重要的一点，没有之一。尽可能在WHERE子句中过滤掉不需要的行。你想想，如果一个表有几百万行数据，你通过WHERE一下子过滤掉了90%，那么GROUP BY和HAVING就只需要处理几十万行了。这比让GROUP BY处理几百万行，再让HAVING过滤掉大部分组，效率要高得多。它减少了聚合操作的数据量，直接降低了CPU和内存的消耗。-- 效率较低的写法：先聚合所有数据，再在HAVING中过滤部门 SELECT Department, AVG(Salary) FROM Employees GROUP BY Department HAVING Department LIKE 'Sales%' AND AVG(Salary) > 60000; -- 优化后的写法：先在WHERE中过滤部门，再进行聚合 SELECT Department, AVG(Salary) FROM Employees WHERE Department LIKE 'Sales%' -- 将非聚合列的过滤提前 GROUP BY Department HAVING AVG(Salary) > 60000;
虽然上面两个查询结果可能相同，但第二个查询在
GROUP BY之前就减少了数据，性能通常会更好。 -
合适的索引： 虽然
HAVING子句本身不直接利用索引（因为它作用于聚合结果），但WHERE子句和GROUP BY子句中使用的列，如果能有合适的索引，将极大提升查询性能。-
WHERE子句中使用的列应该建立索引，这能加速行过滤。 -
GROUP BY子句中使用的列也应该建立索引，这有助于数据库更高效地进行分组操作。有时候，一个复合索引覆盖了GROUP BY和WHERE中的列，效果会更好。
-
避免在
HAVING中使用不必要的复杂聚合： 如果某个聚合函数的结果仅仅是为了在HAVING中过滤，而不需要在SELECT列表中显示，并且这个聚合计算成本很高，可以考虑是否有其他方式实现。不过，通常情况下，为了逻辑清晰，我们会直接在HAVING中使用需要的聚合函数。-
重构复杂查询： 对于那些包含多个
HAVING条件，或者HAVING条件本身就非常复杂的查询，可以考虑使用CTE（Common Table Expressions，公共表表达式）或者子查询来分解查询。这不仅能提高查询的可读性，有时候也能帮助数据库优化器更好地理解和执行查询。-- 使用CTE分解复杂逻辑 WITH DepartmentStats AS ( SELECT Department, AVG(Salary) AS AverageSalary, COUNT(EmployeeID) AS EmployeeCount FROM Employees WHERE HireDate >= '2022-01-01' GROUP BY Department ) SELECT Department, AverageSalary FROM DepartmentStats WHERE AverageSalary > 70000 AND EmployeeCount > 5;这种方式将聚合和过滤分成了两个逻辑步骤，有时候能让数据库优化器有更多空间去选择最优的执行计划。
了解数据库特定的优化器行为： 不同的数据库系统（MySQL, PostgreSQL, SQL Server, Oracle）在处理SQL查询时，其优化器行为可能存在差异。有些数据库可能会尝试在
HAVING之前，将某些条件“下推”到WHERE阶段进行过滤，但这并不是普遍行为。了解你所使用的数据库的特性，可以帮助你写出更符合其优化器习惯的查询。
总之，优化HAVING查询的关键在于减少其前置操作的数据量，并确保WHERE和GROUP BY阶段的效率。只有当这些基础工作做好了，HAVING才能以最快的速度完成它的组过滤任务。
