在业务系统运行中，数据重复导入是常见故障。同一订单因消息重试被写入两次，或运维脚本重复执行造成用户记录翻倍，都会让统计与对账出错。基于唯一键排查并清理重复数据，是解决该问题的标准做法。唯一键可以是数据库主键，也可以是业务层面具有排他性的字段组合，例如手机号加注册渠道。
一、为什么用唯一键排查重复数据
重复数据本质上是违反了某种唯一性约束。如果表已经建有主键或唯一索引，数据库会在写入时拦截一部分重复，但很多重复导入发生在唯一约束建立之前，或者业务唯一键并未落为库表约束。此时只能从数据本身反推哪些行属于重复。
使用唯一键排查的优势在于定位精准。我们不需要比较整行所有字段，只需关注能标识同一实体的关键列。这样既能降低比对成本，也能避免把仅备注不同的两条合法记录误判为重复。相比全表截断重导，基于唯一键的查询与清理对线上影响更小。
二、用分组统计找出重复组合
最基础的排查方式是利用GROUP BY与HAVING统计唯一键的出现次数。以下示例以user_phone与channel构成业务唯一键，查找被重复导入的手机号渠道组合。
-- 查询重复的业务唯一键组合及重复次数 SELECT user_phone, channel, COUNT(*) AS dup_count FROM user_register GROUP BY user_phone, channel HAVING COUNT(*) > 1;
该语句会返回所有出现超过一次的手机号与渠道组合。通过dup_count我们能判断重复规模。若返回结果集很大，说明导入任务被批量重复触发，需要先从上游切断重试逻辑。
这种写法简单直观，适合人工巡检。但它只告诉我们哪些键重复，没有列出具体哪些行该删。要进一步处理，需要把分组结果关联回原表，或者改用窗口函数直接给每行标序号。
三、用窗口函数标记并隔离重复行
SQL标准中的ROW_NUMBER窗口函数可以按唯一键分区，在分区内按写入时间或自增ID排序，给每行编号。编号为1的视为首次导入，其余为重复。下面以MySQL 8与PostgreSQL均支持的语法为例。
-- 给同一业务唯一键内的行编号，保留最早一条
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_phone, channel
ORDER BY id ASC
) AS rn
FROM user_register;
基于上述查询，我们把rn大于1的行插入临时表，作为待清理的重复数据。这样做可以先隔离再确认，防止直接删除导致不可逆损失。
-- 将重复行放入临时表复核
CREATE TABLE user_register_dup_tmp AS
SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_phone, channel
ORDER BY id ASC
) AS rn
FROM user_register
) t
WHERE rn > 1;
-- 确认无误后从原表删除重复行
DELETE FROM user_register
WHERE id IN (SELECT id FROM user_register_dup_tmp);
这种方案的优点是逻辑清晰，且删除操作只针对明确标记的ID。如果担心ORDER BY id ASC不够准确，也可以换成ORDER BY create_time ASC，以业务时间为准保留最先生成的记录。
需要注意，大表上直接DELETE可能锁行较多。建议在低峰期执行，或者分批删除，每批限定一定数量的主键区间，降低主从延迟风险。
四、建立唯一索引防止再次重复
排查完存量数据后，必须从结构上堵住漏洞。对业务唯一键建立唯一索引，可以让数据库在下次重复导入时直接报错，而不是静默落库。
-- 为业务唯一键添加唯一索引 ALTER TABLE user_register ADD UNIQUE INDEX uk_phone_channel (user_phone, channel);
若添加索引时报错提示仍有重复，说明上一步清理不彻底，需重新执行隔离删除逻辑。索引建立后，应用层应捕获唯一键冲突异常，转为幂等更新或忽略处理，从而把导入接口改造为可安全重试。
对于历史表不便加约束的场景，也可以在写入前用SELECT做存在性判断，或借助消息队列的去重机制。但从根本上说，库内唯一约束是最可靠的防线。
五、不同数据库的差异与注意点
主流关系型数据库都支持GROUP BY与窗口函数，但细节略有不同。MySQL 5.7及更早版本不支持窗口函数，需要用用户变量模拟行号；SQL Server与Oracle则原生支持ROW_NUMBER。以下为MySQL 5.7的变量写法示例。
-- MySQL 5.7 用变量模拟分区行号
SET @rn := 0;
SET @prev_key := '';
SELECT id, user_phone, channel, rn
FROM (
SELECT id, user_phone, channel,
@rn := IF(@prev_key = CONCAT(user_phone, channel), @rn + 1, 1) AS rn,
@prev_key := CONCAT(user_phone, channel) AS pk
FROM user_register
ORDER BY user_phone, channel, id ASC
) t
WHERE rn > 1;
该写法依赖排序与变量赋值顺序，在复杂查询中容易出错，仅作为低版本过渡方案。升级数据库或引入中间层计算是更稳妥的选择。
此外，当唯一键包含NULL值时，标准SQL中NULL不等于NULL，GROUP BY会把NULL视为相同分组，但唯一索引通常允许多个NULL。若业务上NULL也代表未知而非相同，需在排查时先用COALESCE转换为占位值再比对。
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| GROUP BY+HAVING | 人工巡检重复键 | 语法简单 | 不返回具体行 |
| ROW_NUMBER窗口 | 精准清理冗余行 | 可标记每行 | 低版本不支持 |
| 唯一索引约束 | 长期防重复 | 库内强约束 | 需先清存量 |
六、总结处理流程
完整的重复导入数据处理流程应为：备份原表，用分组统计确认重复范围，用窗口函数隔离冗余行至临时表，业务复核后删除，最后补齐唯一索引或改造接口幂等。整个过程以唯一键为核心，不过度依赖整行比对，既高效又安全。
在日常故障复盘里，多数重复导入源于缺少幂等设计与唯一约束。技术排查能救急，但架构层面的约束才是避免问题反复发生的根本。建议在项目初期就把业务唯一键明确下来，并落为数据库索引。