如何使用HAVING子句而非WHERE筛选分组后的SQL数据？

本文共计958个文字，预计阅读时间需要4分钟。

在查询中使用WHERE子句进行过滤，前提是在分组（GROUP BY）之前。在这种情况下，只能使用原始表中的字段，不能使用如AVG()、COUNT()这类聚合函数。HAVING子句用于在分组之后进行过滤，因为在此阶段必须完成分组和聚合计算才能生效。

常见错误是把本该放 HAVING 的条件写进 WHERE，比如：WHERE COUNT(*) > 5 —— 这会直接报错，因为 COUNT(*) 此时还没算出来。

• WHERE 可以用：原始列（如 status、created_at）、普通表达式（如 price > 100）
• HAVING 必须用：聚合结果（如 COUNT(id)、AVG(score)）、或已出现在 GROUP BY 中的列
• 如果既要按原始字段过滤，又要按聚合结果过滤，两个子句要同时出现，且 WHERE 必须在 GROUP BY 前

HAVING 必须配合 GROUP BY 使用，否则没意义

单独写 HAVING COUNT(*) > 1 而不加 GROUP BY，在大多数数据库（如 MySQL 5.7+ 严格模式、PostgreSQL）里会报错，提示“HAVING without GROUP BY”或类似错误。

MySQL 旧版本可能允许，但行为等价于对整张表聚合成单组，容易造成误解。实际业务中几乎不会这么用。

• 想查“哪些用户发了超过 3 条评论”，必须写：GROUP BY user_id HAVING COUNT(*) > 3
• 想查“所有评论总数是否超 100”，应该用 SELECT COUNT(*) FROM comments，而不是靠 HAVING
• 有些 ORM 或 BI 工具生成的 SQL 会漏掉 GROUP BY，导致 HAVING 失效或报错，需要人工核对

聚合字段别名在 HAVING 中不能直接用（多数数据库）

很多人习惯给聚合字段起别名，比如 SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept HAVING cnt > 10，但在 PostgreSQL、SQL Server、Oracle 中，这会报错：“cnt does not exist” —— 因为 HAVING 执行时，SELECT 列别名还不可见。

MySQL 是个例外，默认允许（但开启 ONLY_FULL_GROUP_BY 后也会报错），所以依赖别名写法不跨库。

• 安全写法：在 HAVING 中重复聚合表达式，例如 HAVING COUNT(*) > 10
• 或者用子查询/CTE 先算出聚合值，再在外层用别名过滤
• 如果用的是 MySQL 且确认兼容性，可保留别名，但上线前务必在目标环境验证

性能上，WHERE 越早过滤，HAVING 越少计算

WHERE 能减少参与分组的原始行数，直接影响 GROUP BY 的数据量和内存占用；HAVING 是对已分好的组做筛选，无法减少分组过程本身开销。

比如查“2024 年下单超 5 次的 VIP 用户”，应把时间过滤和身份过滤都放在 WHERE，而不是拖到 HAVING：

SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' AND created_at >= '2024-01-01' AND is_vip = 1 GROUP BY user_id HAVING COUNT(*) > 5

如果把 is_vip = 1 放进 HAVING，数据库就得先对全部订单分组，再逐组判断，效率明显下降。

特别注意：某些复杂条件（比如涉及多表 JOIN 后的字段）可能被迫放到 HAVING，这时得权衡逻辑正确性和性能，必要时加索引或改用临时表预处理。