SQL中HAVING子句性能有时优于WHERE子句的深度原因解析

先抛个结论，帮大家省点纠结的时间：HA VING 真的从来就不比 WHERE 性能更好。江湖上流传的“HA VING 更快”，大多是拿错了对比样本，或者是被缓存、数据量这些小细节晃了一下眼。

问题的根源其实就一句话：混淆了“执行阶段”和“数据量”这两个完全不同的概念。把它们的先后顺序和各自能干的事儿理清楚，一切就都明朗了。

WHERE 和 HA VING 的执行顺序不可逆

SQL 引擎执行一条查询，脑子里有张严格的流程图，顺序是固定的：FROM → WHERE → GROUP BY → HA VING → SELECT → ORDER BY。这个顺序意味着什么？

• WHERE 是在分组之前就动手了，它直接对着原始行数据过滤，而且能稳稳地利用索引。这一步跑完，大量数据就被跳过了，后面的计算负担自然就轻。
• HA VING 就不一样了，它必须乖乖等 GROUP BY 把所有活干完——也就是等 SUM()、COUNT() 这些聚合值全部算出来，才能开始工作。这个时候数据已经分好组，中间结果集躺在内存里了。
• 有没有例外？没有。哪怕你写一句 SELECT 1 HA VING 1=1（连 GROUP BY 都没写），多数数据库——像 MySQL 5.7+、PostgreSQL——也会把整张表当成一个单一分组来处理，聚合计算流程一步都绕不过去。

什么情况下会误判 “HA VING 更快”？

实际观察到的“HA VING 查询更快”，几乎都是对比方式出了偏差，或者被隐藏变量干扰了视线：

• 拿一个带 WHERE 但没建索引的查询（比如 WHERE status = 'pending'），跟一个带 HA VING 且恰好命中缓存的查询去比——这就错把缓存效应当成性能优势了。
• 在小数据表上跑测试，HA VING 看起来没“拖慢”，就误以为它“不差”。
• 更常见的是，把 WHERE 写在了 GROUP BY 后面（语法错误），或者漏写了 GROUP BY 导致查询失败，换了 HA VING 后“能跑了”，就以为是优化。

真正影响性能的关键不是子句名，而是数据量落点

决定查询速度的，既不是 WHERE 也不 HA VING，而是“在哪一步减少多少数据”。

• 用 WHERE order_date >= '2026-01-01' 过滤掉 95% 的历史订单，分组时只需要算最近的数据——快是必然的。
• 用 HA VING COUNT(*) > 10 筛选活跃客户，引擎必须先为每个客户完整计数，即使最终只留下 5% 的分组，前面 100% 的聚合计算已经全部跑完了——慢也就情有可原。
• 但如果业务逻辑确实需要聚合后筛选，比如“找出平均响应时间超过 2 秒的接口”，那 HA VING 就是唯一合法的路径。这时候谈“优于 WHERE”没有意义——它们根本不在同一个赛道上竞争。

最后说一个容易被忽略的点：有些数据库，比如 MySQL 8.0，在 HA VING 条件足够简单且字段有索引时，会尝试做下推优化。但这属于引擎内部的“黑盒”行为，不能当作常规武器来依赖。而 WHERE 的索引走查，是稳定、可预期、能通过 explain 验证的。