用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的方案逻辑更集中，原子性更强，执行计划也通常更清晰可控。
说到底，技术实现本身并不复杂。真正的难点往往在于前期的业务确认：到底“哪些列组合起来算重复”？以及“重复了以后，究竟按什么规则保留哪一条”？这两个问题，必须和产品或业务负责人掰扯清楚。代码，只是最终执行这些规则的工具罢了。
