having必须跟在group by后才能生效，用于筛选分组后的聚合结果；where用于分组前行级过滤，二者不可颠倒，且需注意null处理与性能优化。
HAVING 必须跟在 GROUP BY 后面才能生效
很多人写 HAVING 时直接放在 WHERE 后面，结果报错：ERROR: syntax error at or near "HAVING"。这是因为 HAVING 不是独立子句，它只能筛选分组后的聚合结果，必须配合 GROUP BY 使用。没有 GROUP BY，HAVING 就没东西可筛。
典型错误写法：SELECT name FROM users HAVING COUNT(*) > 1 —— 这会直接语法报错。
正确结构是：SELECT ... FROM ... GROUP BY ... HAVING ...
找重复数据：GROUP BY + HAVING COUNT(*) > 1 是标准组合
要查哪些值重复出现，核心思路是：先按目标字段分组，再看每组行数是否大于 1。最常用、最直观的写法就是：
SELECT email FROM users GROUP BY email HAVING COUNT(*) > 1;
注意几点：
-
COUNT(*)统计的是每组的总行数（包括NULL），如果字段本身可能为NULL且你想排除它们，改用COUNT(email) - 想看重复了几遍？把
COUNT(*)加进SELECT列表：SELECT email, COUNT(*) AS cnt - 想查完整记录（不只是重复值）？得用子查询或窗口函数，
HAVING本身只输出分组键，不保留原始行
WHERE 和 HAVING 的分工不能颠倒
常见混淆：把过滤条件错放到 HAVING 里，比如想筛“重复的活跃用户”，却写成：
SELECT user_id FROM orders GROUP BY user_id HAVING status = 'active' AND COUNT(*) > 2;
这会出错，因为 status 不在 GROUP BY 中，也不是聚合结果，数据库不知道该取哪一行的 status。
正确做法是：
- 行级过滤（如
status = 'active'）放WHERE，在分组前就剔除掉不需要的行 - 分组后统计过滤（如
COUNT(*) > 2）才放HAVING
修正后：
SELECT user_id FROM orders WHERE status = 'active' GROUP BY user_id HAVING COUNT(*) > 2;
性能和 NULL 处理容易被忽略
GROUP BY 字段含大量 NULL 时，所有 NULL 会被归为同一组 —— 这意味着 HAVING COUNT(*) > 1 可能意外命中一堆 NULL 值，而你本意只想查非空重复项。
应对方式：
- 明确排除
NULL：WHERE email IS NOT NULL放在GROUP BY前 - 用
COUNT(email)替代COUNT(*)，它自动跳过NULL - 如果字段有索引，
GROUP BY效率通常还行；但若分组键基数极低（比如只有 3 个值），聚合开销不大；反之，千万级唯一值分组就容易慢
真正麻烦的是后续要关联原表取详情——这时候别硬套 HAVING，该上 ROW_NUMBER() 或 COUNT() OVER 窗口函数更稳。
