如何处理SQL重复导入的数据查询：基于唯一键排查数据

查重复数据前先确认唯一键字段

在数据库里谈“重复”，可不能凭感觉。这事儿得有个硬标准：到底哪几个字段组合起来，在业务上应该是唯一的？比如订单表，通常用order_id做主键，那重复就是指出现了两条一模一样的order_id。但如果是日志表，可能压根没设主键，这时候就得靠user_id、event_time和event_type这几个字段联合起来判断了。动手之前，必须先把这套“唯一性组合拳”给明确了。

新手常踩的一个坑是，直接对着SELECT *的结果去重，结果发现删掉的并不是“业务意义上”的重复记录。举个例子，两条记录除了create_time差了一秒，其他内容完全一样，你本来想保留最新的那条，却因为默认排序留下了旧的。所以，确认唯一键是第一步，也是最关键的一步。

• 最直接的方法是用SHOW CREATE TABLE table_name，看看表结构里明确定义的UNIQUE KEY或PRIMARY KEY。
• 如果没有显式的唯一约束怎么办？那就得去翻业务文档，或者直接找后端开发确认逻辑上的唯一性字段，千万别自己猜。
• 还有个小细节要注意：字段值的大小写和空格。MySQL默认不区分大小写，但PostgreSQL是区分的；一个空字符串''和一个空格' '，在某些排序规则下也可能被当作相同值处理。

用 GROUP BY + HA VING 快速定位重复值

想快速知道哪些值重复了？GROUP BY配合HA VING子句是最经典、兼容性也最好的方法，几乎所有主流SQL数据库都支持，完全不需要窗口函数。

它的核心思路非常清晰：按照你认定的唯一键字段进行分组，然后数一数每组里有多少行，数量大于1的，自然就是重复的“嫌疑犯”了。

• 来看个简单例子：查找users表中重复的email。

  SELECT email, COUNT(*) AS cnt
  FROM users
  GROUP BY email
  HA VING COUNT(*) > 1;

• 如果唯一性是由多个字段共同决定的，比如(product_id, store_id)，那么GROUP BY后面就把这两个字段都写上：GROUP BY product_id, store_id。
• 这里有个语法上的小提示：在HA VING子句里，尽量避免使用别名。像HA VING cnt > 1在MySQL 5.7及以上版本可能没问题，但在PostgreSQL和一些老版本的MySQL里会报错。保险起见，还是老老实实写HA VING COUNT(*) > 1。

查出重复行的完整记录（不只是重复值）

光知道哪些值重复了还不够，我们得看到具体的“案发现场”——到底是哪几条完整的记录重复了。只有这样，才能做出判断：保留哪一条，删除哪一条。

到了这一步，单靠GROUP BY就有点力不从心了，需要请出子查询或者窗口函数。这里强烈推荐ROW_NUMBER()窗口函数，它能给每组内的行挨个编号，让你轻松地挑出第一条，或者排除第一条。

• 在MySQL 8.0+、PostgreSQL或SQL Server里，可以这么写：

  SELECT *
  FROM (
    SELECT *,
           ROW_NUMBER() OVER (
             PARTITION BY email ORDER BY updated_at DESC
           ) AS rn
    FROM users
  ) t
  WHERE t.rn > 1;

• 解释一下：PARTITION BY后面跟的就是你去重的依据（也就是唯一键字段），而ORDER BY则决定了你想保留哪一条——通常是按时间戳倒序，这样编号为1的就是最新的记录，保留它，删除编号大于1的。
• 如果你的数据库版本比较老（比如MySQL 5.7），不支持窗口函数怎么办？那就只能用自连接或者相关子查询来实现了，不过这两种方法写起来绕，性能也差一些。这时候，或许该考虑先升级数据库，或者把数据导出到临时表再处理。

避免误删：先备份，再用 WHERE 精确限定范围

查出来只是完成了侦察工作，真正的“手术”是执行DELETE。这一步尤其危险，在线上环境操作时，如果忘了加WHERE条件，或者条件写错了，很可能瞬间清空整张表。

特别要提醒的是，网上很多教程里那种“DELETE FROM t USING t t1 INNER JOIN t t2 ...”的写法，在不同数据库里的语法差异非常大。MySQL和PostgreSQL的写法就完全不同，如果照猫画虎抄错了，不是执行报错，就是删错数据。

• 最安全的做法永远是：先把要删除的那些记录的ID查出来，人工随机抽查几条，确认无误。
• 举个例子，假设要删除重复email中较旧的记录（保留updated_at最大的那条），一种写法是：

  DELETE FROM users
  WHERE id NOT IN (
    SELECT id FROM (
      SELECT MAX(id) AS id
      FROM users
      GROUP BY email
    ) t
  );

• 但这里有个隐藏的陷阱：如果某个email组里包含了NULL值，GROUP BY会把所有NULL归为一组，而NOT IN (subquery)这个操作，一旦子查询结果里出现NULL，整个条件就会失效，导致一条都删不掉。所以，稳妥起见，最好加上WHERE email IS NOT NULL的条件。
• 最后，也是最重要的原则：在执行删除之前，务必先备份。可以用CREATE TABLE users_dup_backup AS SELECT * FROM users WHERE ...这样的语句，把即将被删除的数据单独存成一张备份表。

总结一下，处理重复数据导入，思路要清晰，操作要谨慎。整个过程里，有三个地方最容易出纰漏：一是对唯一键的定义模糊不清；二是忽略了NULL值的特殊处理；三是不了解窗口函数的版本兼容性。把这三点把握住，排查工作就成功了一大半。