WHERE不能过滤“少于N条的分组”因为其执行在GROUP BY之前，无法访问聚合结果；必须用HAVING配合GROUP BY实现分组后筛选。
为什么不能用 WHERE 过滤“少于 N 条的分组”
因为 WHERE 在 GROUP BY 之前执行，它看到的是原始行，不是每组的聚合结果。写 WHERE COUNT(*) > 5 会直接报错：ERROR: aggregate functions are not allowed in WHERE。这不是数据库不支持，而是 SQL 执行顺序决定的——COUNT 还没算出来，根本不存在。
HAVING 是唯一正解，但必须配 GROUP BY
HAVING 的作用对象是分组后的结果集，它天然适合“先分组、再统计、最后按统计值筛选”的逻辑链。但注意：HAVING 单独出现会报错，比如 HAVING COUNT(*) > 3 不加 GROUP BY，MySQL 8.0+ 和 PostgreSQL 都会拒绝：ERROR 1140: In aggregated query without GROUP BY。
- 正确写法：必须显式写出
GROUP BY user_id HAVING COUNT(*) >= 3 - 别依赖 MySQL 5.7 的宽松模式（如只写
GROUP BY dept却在SELECT里选name），PostgreSQL 和 Oracle 会直接报错column "name" must appear in the GROUP BY clause - 想对全表做单一分组判断？用子查询更清晰：
SELECT * FROM (SELECT COUNT(*) AS cnt FROM logs) t WHERE cnt > 1000
常见踩坑点：条件位置错、字段引用错、别名误用
把本该前置的过滤条件塞进 HAVING，等于让数据库白干一堆分组计算。比如 HAVING status = 'paid' AND COUNT(*) >= 3，会导致所有 status 值先被分组，再丢弃非 paid 组——性能差，还可能因未分组字段引发错误。
- 该放
WHERE的：时间范围、状态码、有效标志（如WHERE order_date >= '2026-01-01' AND status = 'completed'） - 该放
HAVING的：聚合结果阈值（如HAVING SUM(amount) > 5000 AND COUNT(*) >= 5） -
HAVING里不能用SELECT别名（HAVING cnt > 5在 PostgreSQL/SQL Server 中非法），得写全表达式：HAVING COUNT(*) > 5 - 如果
SELECT里用了ROUND(AVG(score), 2)，HAVING也得保持一致，否则浮点误差可能导致漏判
性能关键不在 HAVING，而在 WHERE + GROUP BY 索引
HAVING 本身不走索引，它是在内存或临时结果集上扫描过滤，无法跳过数据。真正影响速度的是 GROUP BY 的输入规模和分组效率。
- 先用
WHERE尽量缩小原始数据集（比如加WHERE tenant_id = 123） - 为
GROUP BY字段建组合索引，尤其是和WHERE条件字段一起（如(status, user_id)） - 避免在
HAVING里做复杂计算（如嵌套函数、子查询），它会在每组结果上重复执行 - 如果分组后仍有几十万组，
HAVING COUNT(*) > 100仍需遍历全部，这时要考虑是否该在应用层做二次过滤
实际中最容易被忽略的是：HAVING 不是“后置 WHERE”，它没有下推能力，也不参与计划优化。你写的每个 HAVING 条件，都会在分组完成之后才开始逐条比对——所以前置过滤越干净，后面越省事。
