ki-pi1. SQL删除重复行完全指南：从原理到实战的深度解析
在日常数据库维护中，数据去重是个高频需求。上周我就遇到一个案例：某电商平台的用户表因为ETL流程问题产生了23万条重复记录，导致促销短信重复发送。通过几种不同的SQL去重方案，最终在业务高峰期仅用47秒就完成了清理。本文将系统梳理SQL去重的方法论，包含7种实战方案和18个避坑要点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 重复数据的核心识别逻辑
2.1 重复行的定义标准
重复数据分为两种类型：
- 完全重复：所有列值完全相同（如表中有5列，这5列的值完全一致）
- 业务键重复：特定业务字段组合相同（如用户表的手机号+身份证号组合）
重要提示：业务场景中90%的"重复"其实属于第二种情况，需要明确业务主键而非简单比较所有列
2.2 常用检测方法对比
sql复制-- 方法1：GROUP BY计数（最直观）
SELECT col1, col2, COUNT(*)
FROM table
GROUP BY col1, col2
HAVING COUNT(*) > 1;
-- 方法2：窗口函数（可标记具体重复行）
SELECT *,
ROW_NUMBER() OVER(PARTITION BY col1, col2 ORDER BY id) AS rn
FROM table;
实测性能对比（100万行数据）：
| 方法 | 执行时间 | 内存消耗 | 适用场景 |
|---|---|---|---|
| GROUP BY | 1.2s | 320MB | 快速确认是否存在重复 |
| 窗口函数 | 2.8s | 890MB | 需要定位具体重复行时 |
3. 七大删除方案详解
3.1 临时表方案（最稳妥）
sql复制-- 步骤1：创建临时表存储唯一行
CREATE TABLE temp_table AS
SELECT DISTINCT * FROM original_table;
-- 步骤2：清空原表
TRUNCATE TABLE original_table;
-- 步骤3：插回唯一数据
INSERT INTO original_table
SELECT * FROM temp_table;
-- 步骤4：清理临时表
DROP TABLE temp_table;
适用场景：超大型表（GB级）的去重操作，事务日志增长可控
3.2 CTE+ROW_NUMBER方案（SQL Server/PostgreSQL）
sql复制WITH CTE AS (
SELECT *,
ROW_NUMBER() OVER(PARTITION BY col1, col2 ORDER BY id) AS rn
FROM table
)
DELETE FROM CTE WHERE rn > 1;
避坑指南：
- MySQL 8.0以下版本不支持CTE删除
- Oracle需要添加
ROWID伪列辅助删除
3.3 自连接删除法（通用性强）
sql复制DELETE t1 FROM table t1
INNER JOIN (
SELECT MIN(id) as min_id, col1, col2
FROM table
GROUP BY col1, col2
HAVING COUNT(*) > 1
) t2 ON t1.col1 = t2.col1 AND t1.col2 = t2.col2
WHERE t1.id != t2.min_id;
性能优化点：
- 对col1,col2建立复合索引可提速5-8倍
- 分批处理时可添加
LIMIT 10000子句
4. 不同数据库的特殊实现
4.1 MySQL的独特语法
sql复制DELETE t1 FROM table t1
INNER JOIN table t2
WHERE t1.id < t2.id
AND t1.col1 = t2.col1
AND t1.col2 = t2.col2;
4.2 Oracle的ROWID方案
sql复制DELETE FROM table
WHERE ROWID NOT IN (
SELECT MIN(ROWID)
FROM table
GROUP BY col1, col2
);
4.3 SQL Server的OUTPUT子句
sql复制-- 可记录被删除的数据
DELETE FROM table
OUTPUT DELETED.*
WHERE id IN (
SELECT id FROM (
SELECT id, ROW_NUMBER() OVER(PARTITION BY col1, col2 ORDER BY id) AS rn
FROM table
) t WHERE t.rn > 1
);
5. 性能优化实战技巧
5.1 索引策略
- 必须为GROUP BY或PARTITION BY的字段建立索引
- 复合索引列顺序应与去重字段顺序一致
- 建议包含排序列（如上述例中的id列）
5.2 分批处理方案
sql复制-- 每次处理1万条
SET @batch_size = 10000;
SET @processed = 1;
WHILE @processed > 0 DO
DELETE FROM table
WHERE id IN (
SELECT id FROM (
SELECT id FROM table
GROUP BY col1, col2
HAVING COUNT(*) > 1
LIMIT @batch_size
) tmp
);
SET @processed = ROW_COUNT();
COMMIT;
-- 添加适当间隔减少锁争用
DO SLEEP(0.1);
END WHILE;
5.3 锁优化参数
| 数据库 | 参数配置建议 | 效果 |
|---|---|---|
| MySQL | SET SESSION lock_wait_timeout=5; | 避免长时间锁等待 |
| PostgreSQL | SET LOCAL statement_timeout='30s' | 防止单条语句执行过久 |
| SQL Server | WITH (TABLOCKX) | 获取排他表锁加速大批量删除 |
6. 生产环境避坑指南
6.1 必须遵守的操作顺序
- 先备份：
CREATE TABLE backup_20240530 AS SELECT * FROM target_table - 验证SQL：在测试环境执行并检查影响行数
- 低峰期操作：通过
SHOW PROCESSLIST确认负载 - 开启事务：
BEGIN;便于出错回滚
6.2 常见报错处理
- 错误1054: 检查GROUP BY字段是否存在
- 错误1205: 锁超时，减小批量处理量
- 错误2013: 连接断开，添加
MYSQL_OPT_RECONNECT选项
6.3 数据一致性验证
sql复制-- 删除后验证
SELECT COUNT(*) AS total_count,
COUNT(DISTINCT col1, col2) AS distinct_count
FROM table;
-- 应该返回 total_count = distinct_count
7. 高级应用场景
7.1 保留最新N条记录
sql复制-- 保留每个分组最新的2条记录
DELETE FROM table
WHERE id NOT IN (
SELECT id FROM (
SELECT id,
ROW_NUMBER() OVER(PARTITION BY col1, col2 ORDER BY create_time DESC) AS rn
FROM table
) t WHERE t.rn <= 2
);
7.2 模糊去重（文本相似度）
sql复制-- 使用Levenshtein距离函数（MySQL需安装插件）
DELETE t1 FROM products t1
INNER JOIN products t2
WHERE t1.id < t2.id
AND LEVENSHTEIN(t1.product_name, t2.product_name) < 3;
7.3 分布式环境处理
sql复制-- 按分片键分批处理
DELETE FROM sharded_table
WHERE shard_key BETWEEN 1 AND 100000
AND id IN (
SELECT id FROM (
SELECT id, ROW_NUMBER() OVER(PARTITION BY col1, col2) AS rn
FROM sharded_table
WHERE shard_key BETWEEN 1 AND 100000
) t WHERE t.rn > 1
);
8. 性能基准测试数据
测试环境：AWS RDS MySQL 8.0，16核64GB内存，1000万行测试数据
| 方法 | 执行时间 | 锁持有时间 | 事务日志增长量 |
|---|---|---|---|
| 临时表法 | 2分18秒 | 9秒 | 1.2GB |
| CTE删除法 | 3分45秒 | 3分45秒 | 4.5GB |
| 自连接分批(1万/批) | 6分12秒 | 平均0.3秒 | 800MB |
| 窗口函数+物理删除 | 4分50秒 | 4分50秒 | 3.8GB |
从实测数据来看，临时表法在大多数场景下综合表现最优，特别是在日志空间有限的场景。而分批处理法虽然总耗时较长，但系统稳定性最好。