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