在数据库的日常运维和数据分析中，查找重复数据是个高频操作。但很多时候，我们需要的不仅仅是找出重复项，而是精准定位那些“重复次数超过N次”的记录。比如，排查异常刷单行为，或者清理无效的垃圾注册账号。这背后，考验的是对SQL分组聚合逻辑的深刻理解。
怎么用 GROUP BY 和 HA VING 找出重复超过 N 次的记录
核心思路其实很清晰：先按你怀疑有重复的字段进行分组，然后只留下那些组内行数超过你设定阈值的组。这里的关键在于，WHERE子句在分组前执行，无法使用聚合函数；而HA VING子句是专门用来对分组后的结果进行过滤的。所以，HA VING COUNT(*) > N是唯一的正确路径。
HA VING 里写 COUNT(*) 还是 COUNT(字段)
这是个容易踩坑的细节。简单来说，绝大多数情况下，请使用COUNT(*)。
为什么呢？COUNT(字段名)会忽略该字段值为NULL的行。假设你在排查邮箱重复注册，而有些历史记录的邮箱字段恰好是NULL，使用COUNT(email)就会漏掉这些记录，导致统计不准。而COUNT(*)会忠实统计组内的每一行，无论字段值是否为NULL，结果更可靠。
- 业务场景：查找身份证号、手机号、邮箱等业务唯一键的重复，一律用
COUNT(*)。 - 性能考量：在现代数据库如MySQL 8.0+和PostgreSQL中，
COUNT(*)已经做了充分优化，性能与COUNT(1)无异，无需纠结。 - 例外情况：只有当你的业务逻辑明确要求“只统计该字段非空的记录数”时，才考虑使用
COUNT(字段)。
查多字段组合重复时，GROUP BY 怎么写
现实场景往往更复杂。比如，要找出“同一用户在同一天内下单超过3次”的异常行为。这时，重复的判定标准就涉及user_id和order_date两个字段的组合。
SELECT user_id, DATE(order_time) AS order_date, COUNT(*) AS cnt FROM orders GROUP BY user_id, DATE(order_time) HA VING COUNT(*) > 3;
写这类查询时，有几个技术要点需要留心：
- SELECT与GROUP BY的匹配：
SELECT列表中间出现的、非聚合函数的字段，必须全部包含在GROUP BY子句中。这是SQL标准，在PostgreSQL等数据库中严格执行。MySQL在特定模式下允许不匹配，但为了代码的可移植性和清晰性，建议遵守此规则。 - 函数与别名：在
GROUP BY中直接使用函数（如DATE(order_time)）是允许的。但要注意，如果在SELECT中给这个计算列起了别名（如dt），在某些旧版本的MySQL中，GROUP BY dt可能会报错。最稳妥的做法是GROUP BY里直接写与SELECT中完全相同的表达式。 - 时间精度统一：如果
order_time是TIMESTAMP或带毫秒的类型，直接分组可能会因为微小的毫秒差导致同一天的数据被分到不同组。务必使用DATE()函数或CAST(... AS DATE)来统一精度。
为什么加了索引还是慢？几个关键影响点
语法写对只是第一步，性能调优才是真正的挑战。即使给分组字段建了索引，查询也可能慢如蜗牛，问题往往出在以下几个地方：
- 索引与分组顺序不匹配：这是最常见的性能杀手。对于
GROUP BY a, b，最有效的索引是(a, b)。如果索引是(b, a)，数据库可能无法高效利用它来完成分组排序。 - HA VING条件过于宽松：如果
HA VING COUNT(*) > 1，意味着几乎所有分组都会被保留。当分组数量巨大时，数据库可能被迫使用磁盘临时表来存放中间结果，性能急剧下降。在MySQL中，可以通过SHOW STATUS LIKE 'Created_tmp_disk_tables'来观察是否发生了这种情况。 - NULL值的影响：如果分组字段存在大量
NULL值，它们会被归为同一组。某些数据库引擎处理这种超大分组时效率不高。如果业务上不关心NULL，可以在GROUP BY之前用WHERE field IS NOT NULL提前过滤掉。 - 数据倾斜问题：在PostgreSQL等数据库中，如果数据严重倾斜（例如，某个超级用户占了80%的记录），并行分组聚合（
GROUP BY）可能会因为所有数据都流向同一个工作进程而失去并行优势。这时需要考虑对这类特殊值进行预处理，或者使用分区表来分散压力。
说到底，写出能跑的SQL不难，难的是写出反赌的SQL。这要求开发者不仅要懂语法，更要会看执行计划（EXPLAIN）。通过分析执行计划，你才能准确判断索引是否被正确使用、分组操作是在内存还是磁盘进行，从而找到真正的性能瓶颈并进行精准优化。
