怎样在SQL存储过程中删除重复数据_利用CTE与ROW_NUMBER函数实现

用CTE+ROW_NUMBER()删除重复数据最稳妥，通过PARTITION BY定义重复组、ORDER BY指定保留行（如最小id），避免GROUP BY在DELETE中不支持及NULL分组等问题。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

说到在数据库里清理重复数据，CTE 配合 ROW_NUMBER() 这个组合，可以说是最稳妥、最精准的方案了。它能明确地告诉你每组数据里保留哪一条，而且完全不依赖表里有没有唯一键。

为什么不能直接 DELETE 加 GROUP BY？

很多朋友第一个念头可能是用 GROUP BY 分组后直接删，但这条路在 SQL Server 和大多数主流数据库里是走不通的。数据库引擎会直接报错：Incorrect syntax near the keyword 'GROUP'。原因很简单，DELETE 语句的设计就不支持直接使用 GROUP BY 或聚合函数。那怎么办呢？这时候 CTE（公用表表达式）就派上用场了。它相当于创建了一个临时的、可更新的逻辑视图，让我们能把 ROW_NUMBER() 计算出来的序号，直接用在 DELETE 操作上。

ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY

光写一个 ROW_NUMBER() OVER () 是没意义的，它只会给全表所有行编个流水号（1, 2, 3...），根本区分不开哪些是重复组。真正的精髓在于后面两个子句：

• PARTITION BY col1, col2：这个子句定义了“什么叫重复”。你把哪些列放进来，系统就按这些列的值是否完全相同来分组。
• ORDER BY id ASC：这个子句决定了在每一组重复数据里，你打算留下哪一条。通常我们会按主键 id 升序排，保留最小的那条，或者按时间戳排序，保留最新或最旧的那条。

来看一个经典例子：删除 users 表中 email 地址重复的记录，只保留 id 最小的那一条。

WITH dup AS (
  SELECT id, email,
         ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
  FROM users
)
DELETE FROM dup WHERE rn > 1;

执行前务必加事务和验证

上面这条语句是动真格的，执行了数据就没了。所以动手之前，有几个常见的坑必须绕开：

• 排序方向搞反了：如果你本意是留旧删新，却写了 ORDER BY id DESC，那结果就是留新删旧，完全反了。
• 忽略了 NULL 值：在 SQL 的世界里，NULL = NULL 的结果是未知（false）。这意味着，如果 PARTITION BY 的列里有多个 NULL，它们不会被归为同一组。如果你的业务认为 NULL 也应该被视为相同值，就需要先用 ISNULL(email, '') 之类的函数处理一下。
• 忘了先预览：在执行 DELETE 前，务必把 DELETE FROM dup WHERE rn > 1 换成 SELECT * FROM dup WHERE rn > 1 跑一遍，看看即将被删除的到底是哪些数据。
• 生产环境裸奔：在生产数据库操作，一定要套上事务：BEGIN TRAN; ... (你的DELETE语句) ...; ROLLBACK;。先回滚检查，确认无误后再 COMMIT。

替代方案对比：临时表 or GROUP BY + 子查询？

当然，市面上也有其他方法。比如，有人会用临时表：先 SELECT MIN(id) INTO #keep FROM t GROUP BY cols 找出要保留的ID，再 DELETE WHERE id NOT IN (SELECT id FROM #keep)。但这个方法隐患不少：

• 如果原表没有主键，或者 id 本身就不唯一，MIN(id) 选出来的可能并不是你想保留的那行。
• 使用 NOT IN 时，如果子查询结果集里包含 NULL，那么整个条件会直接返回空，导致 DELETE 语句静默失效，一条都删不掉。
• 相比之下，CTE 的方案逻辑更集中，原子性更强，执行计划也通常更清晰可控。

说到底，技术实现本身并不复杂。真正的难点往往在于前期的业务确认：到底“哪些列组合起来算重复”？以及“重复了以后，究竟按什么规则保留哪一条”？这两个问题，必须和产品或业务负责人掰扯清楚。代码，只是最终执行这些规则的工具罢了。