直接用 HAVING COUNT(*) > N 筛选分组，WHERE 无法访问聚合值，否则报错；HAVING 必须跟在 GROUP BY 后，且 WHERE 应先过滤原始数据以提升性能。
GROUP BY 后怎么筛出记录数超 N 的分组
直接用 HAVING COUNT(*) > N，不是 WHERE。WHERE 在分组前过滤行，HAVING 才能对分组后的聚合结果做条件判断。
常见错误是写成 WHERE COUNT(*) > N，会报错 ERROR: aggregate functions are not allowed in WHERE —— 因为 WHERE 阶段 COUNT(*) 还没算出来。
-
HAVING必须跟在GROUP BY后面，顺序不能颠倒 - 如果同时有
WHERE和HAVING，WHERE 先执行（减少分组前的数据量），再分组，最后 HAVING 筛分组 -
HAVING中可直接用COUNT(*)、COUNT(列名)，但注意COUNT(列名)会忽略 NULL 值
查“每个分类下订单数 ≥ 5”的商品类别
假设表 orders 有字段 category 和 order_id，要找出订单数不少于 5 的类别：
SELECT category, COUNT(*) AS cnt FROM orders GROUP BY category HAVING COUNT(*) >= 5;
这里 COUNT(*) 统计每组行数，HAVING 对这个统计值做比较。如果想排除 category 为 NULL 的组，得额外加 WHERE category IS NOT NULL —— HAVING 本身不负责过滤原始 NULL 值。
- 别在
HAVING里用别名cnt（如HAVING cnt >= 5），多数数据库（PostgreSQL、SQL Server）不支持，MySQL 8.0+ 才允许 - 如果需要排序，
ORDER BY放在HAVING之后，可用别名（如ORDER BY cnt DESC）
HAVING 和 WHERE 性能差异明显吗
有，而且很实际：WHERE 能利用索引快速剪枝，HAVING 是分组后扫描聚合结果，无法走索引。
比如查“用户登录次数 > 10 的活跃用户”，如果先用 WHERE login_time > '2024-01-01' 缩小数据范围，再分组，比全表分组后 HAVING COUNT(*) > 10 快得多。
- 尽量把能下推的过滤条件（时间范围、状态码、非空约束等）写进
WHERE -
HAVING适合逻辑必须依赖聚合结果的场景，例如“平均单价 > 100”、“最大下单量 ≠ 最小下单量” - 某些数据库（如 MySQL）对
HAVING后的表达式优化有限，复杂计算建议用子查询或 CTE 拆开
COUNT(1)、COUNT(*)、COUNT(列名) 在 HAVING 里有区别吗
有。虽然日常用 COUNT(*) 最安全，但在 HAVING 中选错可能漏数据。
COUNT(*) 统计所有行（含全 NULL 行）；COUNT(列名) 只统计该列非 NULL 的行；COUNT(1) 和 COUNT(*) 行为一致（1 是常量，不会为 NULL）。
- 如果分组依据列（如
GROUP BY category）本身允许 NULL，且你想把category IS NULL当作一个独立分组，就用COUNT(*) - 如果业务上认为
category为空的记录不该参与统计，用COUNT(category)会自动跳过它们 —— 但注意，这会让该分组的计数变小，可能影响HAVING判断 - 别为了“看起来快”换
COUNT(1)，现代数据库对三者优化程度基本一致，语义清晰更重要
WHERE 和 HAVING 的职责边界 —— 前者管“哪些行参与分组”，后者管“哪些分组保留下来”。混淆这点，轻则结果不对，重则查不出数据还查不出错在哪。 
