SQL怎样筛选出记录数大于1的重复数据_利用HA VING COUNT过滤
为什么 WHERE 不能用 COUNT() 筛重复行
很多朋友在写SQL时，第一个念头可能就是：用WHERE COUNT(*) > 1把重复行找出来。但一执行，数据库就会报错：ERROR: aggregate functions are not allowed in WHERE。
问题出在SQL的执行顺序上。WHERE子句是在数据分组之前进行过滤的，而COUNT()这类聚合函数，必须在数据被GROUP BY分组之后才能计算出结果。这就好比，你还没把学生按班级分好组，就想数每个班有多少人，这显然是行不通的。
HA VING 必须和 GROUP BY 配合使用
那么，正确的姿势是什么？答案是HA VING。这个子句是专门用来在分组之后对聚合结果进行筛选的。想找出哪些字段组合重复了，思路很清晰：先按这些字段分组，再筛选出计数大于1的组。
SELECT user_id, email FROM users GROUP BY user_id, email HA VING COUNT(*) > 1;
这里有三个关键点需要特别注意：
- 只写
GROUP BY而不加HA VING，你只能看到所有分组的计数，却无法自动过滤出重复项。 HA VING后面只能跟分组字段或者聚合函数表达式。如果你想写类似HA VING created_at > '2023-01-01'这样的条件，而created_at又不在GROUP BY中，数据库会直接报错。- 从MySQL 5.7版本开始，默认开启了
sql_mode=only_full_group_by规则。这意味着，SELECT列表里的每一列，要么必须出现在GROUP BY子句中，要么必须被聚合函数包裹，否则查询就无法执行。这个设置虽然严格，但能有效避免语义模糊的查询结果。
想查完整重复记录（不止分组字段）？用窗口函数或自关联
上面GROUP BY + HA VING的方法，返回的是去重后的分组键值，而不是原始的所有重复行。如果你需要看到完整的、包含所有字段的重复记录，更推荐使用窗口函数。
SELECT *
FROM (
SELECT *,
COUNT(*) OVER (PARTITION BY user_id, email) AS cnt
FROM users
) t
WHERE cnt > 1;
这种方法有几个明显的优势：
- 窗口函数（如
COUNT() OVER）不会改变结果集的行数，它只是为每一行计算一个所属分组的计数值，因此可以轻松保留所有原始字段。 - 目前，PostgreSQL、SQL Server、MySQL 8.0+以及Oracle等主流数据库都已支持窗口函数。
- 当然，如果你的数据库版本较老（比如MySQL 5.6），窗口函数不可用，那就得用“自关联”这种传统方法了：先用子查询通过
GROUP BY + HA VING找出重复的键值，再通过JOIN回原表，把完整的记录捞出来。
性能要注意：重复字段上建联合索引
当数据表体积庞大时，按多个字段进行GROUP BY操作可能会成为性能瓶颈。如果业务上经常需要按某几个字段组合来排查重复数据，那么为这些字段建立联合索引是必不可少的优化手段。
CREATE INDEX idx_user_email ON users(user_id, email);
关于索引，有几点实践经验值得分享：
- 索引列的顺序至关重要。通常，应该把最常用于等值查询的列放在前面。例如，如果你的查询模式是
WHERE user_id = ? AND email = ?，那么(user_id, email)的顺序就是合理的。 - 联合索引有其局限性。如果你经常需要单独对
email字段进行重复查询，那么上面这个(user_id, email)索引的效果就会大打折扣，此时可能需要额外为email建立单列索引。 - 需要明确的是，
HA VING COUNT(*) > 1这个过滤条件本身是无法利用索引的。但是，它前面的GROUP BY分组操作，却可以借助索引来大幅提升排序和分组的速度。
最后，还有一个在实际业务中极易被忽略的细节：对NULL值的处理。在GROUP BY的逻辑里，所有的NULL值会被视为相等而归入同一组。但从业务语义上讲，空值往往不应该被算作有效的重复数据。因此，稳妥的做法是在分组前就显式地排除它们：WHERE user_id IS NOT NULL AND email IS NOT NULL。这个小小的步骤，常常能避免后续数据清洗时的大的麻烦。
