在SQL查询的执行逻辑中，HAVING子句和WHERE子句的作用阶段存在明显差异，这种差异直接影响了查询的性能表现。很多开发者习惯将所有过滤条件都写在HAVING子句中，却忽略了前置过滤对性能的提升作用。
HAVING子句与WHERE子句的执行顺序差异
SQL查询的标准执行顺序中，WHERE子句的执行早于GROUP BY和HAVING子句。具体流程如下：
- 第一步：执行FROM子句，获取基础数据表
- 第二步：执行WHERE子句，对基础数据进行初步过滤
- 第三步：执行GROUP BY子句，对过滤后的数据进行分组
- 第四步：执行聚合函数，计算每个分组的聚合值
- 第五步：执行HAVING子句，对分组后的结果进行过滤
- 第六步：执行SELECT子句，返回最终需要的字段
从执行顺序可以看出，WHERE子句过滤的是原始数据，而HAVING子句过滤的是已经分组聚合后的结果集。如果过滤条件可以前置到WHERE中，就能减少后续分组和聚合处理的数据量，自然能提升查询效率。
性能对比示例
假设我们有一张订单表order_info，表结构如下：
CREATE TABLE order_info (
order_id INT PRIMARY KEY,
user_id INT,
order_amount DECIMAL(10,2),
order_status VARCHAR(20),
create_time DATETIME
);
现在需要查询订单金额大于100且状态为已支付的用户，以及他们的总订单金额，要求总订单金额超过500。
写法一：所有条件都放在HAVING中
SELECT user_id, SUM(order_amount) AS total_amount FROM order_info GROUP BY user_id HAVING order_amount > 100 AND order_status = '已支付' AND SUM(order_amount) > 500;
这种写法会先对所有用户的订单进行分组聚合，再对分组后的结果过滤订单金额和状态，即使很多订单本身金额不足100或者状态不是已支付，也会先参与分组计算，浪费大量计算资源。
写法二：前置过滤条件到WHERE中
SELECT user_id, SUM(order_amount) AS total_amount FROM order_info WHERE order_amount > 100 AND order_status = '已支付' GROUP BY user_id HAVING SUM(order_amount) > 500;
这种写法先通过WHERE子句筛掉了金额不足100和状态不是已支付的订单，只有符合这两个条件的订单才会参与后续的分组和聚合计算，大幅减少了中间处理的数据量。
适合前置到WHERE的过滤条件
并不是所有HAVING子句中的条件都可以前置到WHERE中，需要满足以下条件：
- 过滤条件不涉及聚合函数的结果，比如上面的
order_amount > 100和order_status = '已支付'都是针对单条记录的过滤，和分组聚合无关 - 过滤条件在分组前就可以确定是否符合要求，不需要依赖分组后的计算结果
而像SUM(order_amount) > 500这类依赖聚合函数结果的条件，只能在分组聚合之后通过HAVING子句过滤，无法前置到WHERE中。
优化注意事项
在将HAVING条件前置到WHERE时，还需要注意以下几点：
- 前置的过滤字段如果有索引，能进一步提升WHERE子句的过滤效率，建议对常用的过滤字段建立合适的索引
- 不要盲目将所有HAVING条件都移到WHERE中，需要先判断条件是否依赖聚合结果，避免SQL执行报错
- 对于复杂的查询，可以通过
EXPLAIN命令查看两种写法的执行计划，对比实际的数据扫描量和执行耗时，选择更优的写法
通过合理将HAVING子句中不依赖聚合结果的过滤条件前置到WHERE子句，是SQL查询性能优化的常用手段，能在不改变查询结果的前提下，有效减少数据库的计算压力，提升查询响应速度。