在编写SQL查询时，条件过滤是最常见的操作之一。WHERE和HAVING两个子句看起来功能相似，都能对数据进行筛选，但它们在查询的执行流程中处于完全不同的阶段，适用的对象也不同。理解这两者的区别，不仅关系到SQL能否正确执行，还直接影响查询性能。本文将围绕条件过滤机制，深入剖析WHERE与HAVING的差异。
一、从逻辑执行顺序看两者的本质区别
SQL语句的书写顺序和实际执行顺序并不一致。一条完整的SELECT语句，其逻辑执行顺序大致是：FROM先确定数据来源，接着WHERE对原始行进行过滤，然后GROUP BY进行分组，随后HAVING对分组结果进行过滤，再之后才是SELECT选取列，最后ORDER BY排序。这个顺序揭示了两者最核心的区别：WHERE作用于分组之前的原始数据行，HAVING作用于分组之后的聚合结果。
正因为执行顺序不同，两者能引用的对象也不同。WHERE阶段数据还没有分组，所以它只能引用表中的原始列，不能使用SUM、COUNT、AVG等聚合函数；而HAVING阶段分组已经完成，聚合值已经计算出来，所以HAVING既可以引用聚合函数，也可以引用分组字段。下面用一个订单表orders来演示典型用法：
-- 查询总金额超过1000的用户，且只统计已支付的订单 SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' -- 先过滤原始行：只保留已支付订单 GROUP BY user_id HAVING SUM(amount) > 1000; -- 再过滤分组：只保留总金额超1000的用户
这条查询清晰地展示了分工：WHERE负责剔除不符合条件的原始记录，HAVING负责筛选聚合后的组。如果把 WHERE SUM(amount) > 1000 写进WHERE子句，数据库会直接报错，提示聚合函数不允许出现在WHERE中。这是因为执行WHERE时分组尚未发生，每一行的聚合值根本不存在，数据库无从比较。
二、聚合函数为什么不能用在WHERE中
聚合函数的计算依赖于一组行，而WHERE是对单行逐条判断的。数据库处理WHERE时，是拿着一行一行的数据去匹配条件，此时SUM、COUNT这类需要多行参与计算的值还没有产生。换句话说，WHERE阶段的上下文中根本没有聚合结果可用，所以任何数据库引擎都会拒绝这种写法。
有些开发者会想用子查询来绕过这个限制，例如先在子查询中计算聚合值，再在外层用WHERE判断。这种写法在逻辑上是可行的，但可读性不如HAVING。两种等价写法对比如下：
-- 写法一：使用HAVING过滤聚合结果（推荐）
SELECT dept_id, AVG(salary) AS avg_salary
FROM employees
GROUP BY dept_id
HAVING AVG(salary) > 8000;
-- 写法二：使用子查询配合WHERE（逻辑等价）
SELECT t.dept_id, t.avg_salary
FROM (
SELECT dept_id, AVG(salary) AS avg_salary
FROM employees
GROUP BY dept_id
) t
WHERE t.avg_salary > 8000;
需要注意一个细节：HAVING中引用的聚合表达式最好与SELECT中保持一致，或者直接重新书写聚合表达式。部分数据库支持在HAVING中使用列别名，例如MySQL允许 HAVING avg_salary > 8000，但这是非标准语法，在SQL Server、Oracle等数据库中会报错，跨数据库迁移时应避免依赖这种写法。
三、性能差异：过滤越早越有利
从性能角度看，条件过滤应该尽早执行。WHERE在分组之前生效，不符合条件的行不会参与分组和聚合计算，数据量被提前削减；HAVING则是在聚合完成之后才过滤，所有行都会先经历分组和聚合的开销，即使最终被丢弃。因此，凡是既能写在WHERE又能写在HAVING中的普通条件，都应该优先写在WHERE里。
-- 不推荐：普通条件写在HAVING中，所有行都参与分组 SELECT dept_id, COUNT(*) AS emp_count FROM employees GROUP BY dept_id HAVING dept_id > 100 AND COUNT(*) > 5; -- 推荐：普通条件下推到WHERE，减少参与分组的数据量 SELECT dept_id, COUNT(*) AS emp_count FROM employees WHERE dept_id > 100 GROUP BY dept_id HAVING COUNT(*) > 5;
两张写法在结果上完全相同，但在大数据量表上性能差距可能非常明显。假设employees有千万行数据，其中dept_id大于100的只占百分之十，第一种写法要对全部一千万行做分组聚合，第二种只需处理一百万行，聚合阶段的开销直接降低了一个数量级。
此外，WHERE条件更容易被优化器利用来命中索引。比如 WHERE dept_id > 100 如果dept_id列上有索引，数据库可以通过索引范围扫描快速定位数据；而放在HAVING中的条件只能在聚合结果集上逐条判断，无法利用底层索引。这也是很多慢SQL优化的常见手段：把HAVING中不必要的条件挪回WHERE。
四、常见误区与实战注意事项
第一个常见误区是用HAVING完全替代WHERE。虽然大多数数据库允许在不写GROUP BY的情况下使用HAVING，此时整个结果集被视为一个组，但滥用HAVING会让查询意图变得模糊，也丧失了提前过滤的性能优势。正确原则是：普通列条件放WHERE，聚合条件才用HAVING。
第二个误区是混淆分组字段在两处的可用性。WHERE中不能出现分组字段之外的限制吗？恰恰相反，WHERE只能使用分组之前的原始列，而HAVING虽然语法上允许引用非分组、非聚合的列，但在严格模式（如MySQL的ONLY_FULL_GROUP_BY）下会报错，因为SELECT中未出现的非聚合列在HAVING中同样不受支持。规范做法是HAVING中只出现聚合函数和GROUP BY中声明的列。
第三个需要注意的点是NULL值的处理。WHERE和HAVING对NULL的判断逻辑一致：= NULL 永远返回未知，必须使用 IS NULL 或 IS NOT NULL。同时，GROUP BY会把NULL归为同一组，如果分组字段存在NULL，HAVING过滤聚合结果时要留意这一组的统计口径是否符合业务预期。
总结一下核心结论：WHERE在分组前过滤原始行，速度快、可用索引，但不能使用聚合函数；HAVING在分组后过滤聚合结果，专门配合GROUP BY和聚合函数使用。编写SQL时遵循普通条件放WHERE、聚合条件放HAVING的原则，既能保证语法正确，也能让查询获得最佳执行效率。
SQL WHERE和HAVING区别条件过滤聚合函数修改时间：2026-09-01 20:00:58