GROUP BY + HAVING 筛选分组计数达标数据必须用 HAVING COUNT() >= N，不可用 WHERE（因 WHERE 在分组前执行，无法访问聚合结果）；COUNT() 统计所有行（含NULL），COUNT(列名) 仅统计非NULL值；HAVING 不走索引，大表需先用 WHERE 缩小数据范围。
用 GROUP BY + HAVING 筛选分组计数达标的数据
直接在 GROUP BY 后加 HAVING COUNT(*) >= N，这是最常用也最有效的做法。注意不能用 WHERE，因为 COUNT() 是聚合结果，WHERE 在分组前执行，此时还没算出每组的行数。
常见错误是写成 WHERE COUNT(*) >= 10，会报错 Invalid use of group function —— MySQL 的典型提示，其他数据库类似。
-
HAVING必须跟在GROUP BY后面（或没有GROUP BY但有聚合函数时隐式分组） - 如果还要查原始字段（比如每个组的
user_id列表），得配合GROUP_CONCAT()或窗口函数，不能直接SELECT * - 阈值
N可以是字面量（如5），也可以是子查询结果，但不能是未聚合的列名
MySQL 中 COUNT(*) 和 COUNT(列名) 的行为差异
对空值敏感与否直接影响阈值判断是否准确。比如按 status 分组，想找出“至少有 3 条非空 status 记录”的分组，就得用 COUNT(status)；若用 COUNT(*)，哪怕该组 5 行里有 3 行 status IS NULL，它仍返回 5。
-
COUNT(*)统计所有行（包括含 NULL 的行） -
COUNT(col)只统计col IS NOT NULL的行 - 若列允许 NULL 且业务语义上“空值不算有效记录”，必须显式写
COUNT(列名)
PostgreSQL / SQL Server 中 HAVING 的兼容写法
标准 SQL 允许 HAVING 引用 SELECT 列别名，但 PostgreSQL 不支持，SQL Server 从 2022 起才支持。所以稳妥写法是重复表达式，而不是依赖别名。
例如下面这句在 PostgreSQL 会报错：HAVING cnt >= 10（假设前面写了 COUNT(*) AS cnt）。
- 正确写法：
HAVING COUNT(*) >= 10 - 如果 COUNT 逻辑复杂（比如带条件），建议用子查询或 CTE 避免重复写
- SQL Server 2019 及更早版本同样不认别名，别心存侥幸
性能隐患：HAVING 过滤不了索引，大表慎用
HAVING 是在分组完成之后过滤，无法利用索引加速——即使你对分组字段建了索引，HAVING COUNT(*) > 100 仍要扫完整个分组结果集。
- 如果数据量大且阈值很高（比如只留 count > 10000 的组），先用
WHERE尽可能缩小输入范围（如加时间范围、状态过滤） - 考虑是否真需要实时计算：高频查询可预存分组计数到汇总表，用触发器或定时任务更新
- EXPLAIN 查看执行计划时，注意
HAVING对应的过滤步骤是否出现在最后，且没被下推
分组后过滤这件事本身简单，但实际慢往往不是语法写错，而是没意识到 HAVING 不走索引，也没前置收缩数据规模。
