HA VING 和 WHERE 看起来都像是“过滤”工具，但本质差得挺远。简单来说：WHERE 在数据分组之前就把不想要的行砍掉了，而 HA VING 是在分组计算完事后，再决定哪些组能留下来。如果你写过 WHERE COUNT(*) > 1 然后收到报错，那多半是没搞清楚这个顺序——因为 COUNT(*) 是聚合函数，WHERE 里压根不允许用聚合结果做条件。
HA VING 和 WHERE 的区别到底在哪
WHERE 在分组前过滤行，HA VING 在分组后过滤组。常见错误现象：ERROR: aggregate functions are not allowed in WHERE。这时候就得换 HA VING。
- WHERE 作用于原始数据行，支持字段名、普通表达式、子查询（非相关）
- HA VING 作用于 GROUP BY 产生的分组结果，必须配合 GROUP BY 使用，且可直接使用聚合函数
- 执行顺序是：FROM → WHERE → GROUP BY → HA VING → SELECT → ORDER BY
HA VING 必须和 GROUP BY 一起用吗
绝大多数主流 SQL 引擎（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）都强制要求：只要用了 HA VING，就必须有 GROUP BY。否则报错 ERROR: HA VING clause requires GROUP BY 或类似提示。
- 想只查“订单数 > 5 的用户”，必须写
GROUP BY user_id，再加HA VING COUNT(*) > 5 - 如果漏写 GROUP BY，PostgreSQL 直接拒绝；SQLite 会报
misuse of aggregate - MySQL 8.0 默认启用 ONLY_FULL_GROUP_BY，也会报错
例外情况极少：某些旧版 MySQL（5.7 及之前）在 SQL_MODE 不严格时允许没有 GROUP BY 的 HA VING，但行为不可靠，返回结果可能随机取某一行的聚合值，不建议依赖。
HA VING 中能用非聚合字段吗
可以，但仅限于出现在 GROUP BY 子句中的字段（或其函数表达式），否则会出错。
例如 GROUP BY status 后，HA VING status = 'active' 是合法的；但 HA VING created_at > '2023-01-01' 就不行——除非 created_at 也在 GROUP BY 里，或者套上聚合函数如 MAX(created_at)。
- PostgreSQL 要求 HA VING 中所有非聚合列必须在 GROUP BY 中显式列出
- MySQL 在 ONLY_FULL_GROUP_BY 开启时同样校验，关闭后可能静默返回错误结果
- 推荐写法：把筛选逻辑尽量前置到 WHERE（提高性能），HA VING 只留真正需要基于聚合结果的条件
性能影响和优化提示
HA VING 过滤发生在分组计算完成之后，意味着数据库必须先算出所有分组的聚合值，再丢弃不满足条件的组。数据量大时，这比 WHERE 过滤代价高得多。
- 优先用 WHERE 过滤掉大量无关行（比如
WHERE deleted = false），减少 GROUP BY 输入量 - 确保 GROUP BY 字段上有索引，尤其当配合 HA VING 中的聚合条件（如
HA VING SUM(amount) > 1000）时 - 避免在 HA VING 中用复杂子查询或标量函数——它们会在每个分组上重复执行
- EXPLAIN 分析时注意看是否出现 “HashAggregate” 后紧跟 “Filter” —— 那就是 HA VING 在起作用
最常被忽略的一点：HA VING 不是万能的分组筛选工具，它解决的是“哪些组符合条件”，而不是“组内哪些行符合条件”。后者得靠窗口函数或子查询配合 WHERE。
