最可靠方法是用CTE包裹ROW_NUMBER()后DELETE，必须指定PARTITION BY和稳定ORDER BY，删前验证重复分布，删后重建索引并更新统计信息。
直接用 ROW_NUMBER() + CTE 删除重复行最可靠
SQL Server 2005+ 全支持窗口函数，ROW_NUMBER() 是去重的核心工具。它不依赖索引、不触发全表扫描，且能精确控制“留哪条”，比 DISTINCT 或子查询更可控。关键不是“查出来”，而是“删干净”——尤其在千万级表上，必须用 CTE 包裹后再 DELETE，否则会报错。
常见错误是写成：DELETE FROM (SELECT ..., ROW_NUMBER() ...) —— SQL Server 不允许直接删子查询结果。必须用 CTE 定义别名，再对别名执行 DELETE。
- 确保
PARTITION BY字段组合真正代表“重复逻辑”，比如去重访客日志，应是PARTITION BY user_id, visit_date，而不是只按user_id -
ORDER BY要选有业务意义的字段：要留最新记录就用create_time DESC，要留最早就用id ASC - 务必加
WHERE rn > 1，不能漏掉条件，否则整张表被清空
WITH cte AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_id, visit_date
ORDER BY create_time DESC
) AS rn
FROM logs
)
DELETE FROM cte WHERE rn > 1;
去重前必须先验证重复分布，别盲目跑 DELETE
海量数据下，一次误操作可能锁表数分钟。先用 GROUP BY + HAVING 快速确认重复模式，比直接删更安全。
例如发现 user_id + visit_date 组合中，95% 的重复组只有 2–3 条记录，但有 0.1% 的组高达 200+ 条——这说明部分用户埋点异常，需人工抽检，不能一刀切删。
- 查重复组合数量：
SELECT COUNT(*) FROM (SELECT user_id, visit_date FROM logs GROUP BY user_id, visit_date HAVING COUNT(*) > 1) t - 查最大重复频次：
SELECT MAX(cnt) FROM (SELECT COUNT(*) AS cnt FROM logs GROUP BY user_id, visit_date) t - 抽样看典型重复块：
SELECT TOP 10 *, COUNT(*) OVER (PARTITION BY user_id, visit_date) AS dup_cnt FROM logs ORDER BY dup_cnt DESC
ORDER BY (SELECT NULL) 是性能陷阱，慎用
有人为“省事”在 ROW_NUMBER() 里写 ORDER BY (SELECT NULL)，以为只是随便排个序。但 SQL Server 会把它解释为“无确定顺序”，可能导致同一语句多次执行返回不同结果——删掉的记录不固定，后续数据一致性无法保障。
即使业务上真不关心留哪条，也应显式指定一个稳定字段，比如 id ASC 或 create_time ASC。主键或时间戳字段几乎总有索引，排序开销极小，还能避免隐式转换和统计信息失效问题。
- ✅ 推荐：
ORDER BY id ASC（假设id是自增主键） - ❌ 避免：
ORDER BY (SELECT NULL)或空ORDER BY - ⚠️ 注意：
ORDER BY create_time若该列无索引，大数据量下排序成本高，可先建索引再执行
物理删除后记得重建索引和更新统计信息
删掉几十万行后，聚集索引页会出现大量空洞，非聚集索引的叶级碎片率飙升，后续查询性能可能断崖式下跌。这不是“去重完成”的终点，而是维护的起点。
尤其当原表有高频查询依赖 user_id 或 visit_date 等字段时，碎片直接影响执行计划选择。别跳过这步。
- 重建主键聚集索引：
ALTER INDEX PK_logs ON logs REBUILD - 更新统计信息：
UPDATE STATISTICS logs WITH FULLSCAN（FULLSCAN对去重后数据更准确） - 如果用了分区表，确认是否需要
REORGANIZE分区而非全表REBUILD
真正难的不是写出那几行 ROW_NUMBER()，而是判断哪些重复该删、哪些该留、删完系统还稳不稳。数据量越大，越要靠前置验证和事后维护兜底，而不是只信一条 DELETE 语句。
