如何使用SQL ROW_NUMBER()函数高效地删除表中的重复记录？-SQL-PHP中文网

row_number()配合cte是删重最稳妥的方式，因sql server/postgresql等不支持窗口函数直接用于delete或where，必须用cte包裹生成序号后再按rn>1删除，且需确保partition by覆盖全部重复判定列、order by明确保留规则，并执行select预览验证。

如何使用sql row_number()函数高效地删除表中的重复记录？

ROW_NUMBER() 配合 CTE 是删重最稳妥的方式

直接在 DELETE 语句里用 ROW_NUMBER() 会报错（SQL Server/PostgreSQL 不支持窗口函数出现在 WHERE 或 DELETE 的顶层），必须借助 CTE 或子查询包裹。CTE 写法清晰、可读性强，且能精准控制“保留哪一条”——比如按时间取最新、按 ID 取最小。

常见错误是写成：DELETE FROM t WHERE ROW_NUMBER() OVER (...) > 1，这语法非法，数据库直接拒绝执行。

必须把 ROW_NUMBER() 放在 CTE 或派生表中，生成带序号的临时结果集
CTE 中的排序字段（ORDER BY）决定“谁被保留”：想要保留最新记录就按 created_at DESC，保留最早就用 ASC
分区字段（PARTITION BY）必须覆盖所有判定重复的列，漏一列就可能误删或漏删

删除前务必先验证哪些行会被删掉

删重是高危操作，没备份或没预览就执行 DELETE 容易翻车。永远先用 SELECT 替代 DELETE，确认逻辑正确再动手。

WITH dupes AS (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY email, user_id ORDER BY updated_at DESC
         ) AS rn
  FROM users
)
SELECT * FROM dupes WHERE rn > 1;

这个查询能直观看到所有将被删除的重复行。注意检查 PARTITION BY 列是否真能唯一标识业务上的“重复”——比如两个用户碰巧邮箱相同但属于不同租户，PARTITION BY email 就不合理，得加上 tenant_id。

AVC.AI

AVC.AI是一款提供图片和视频增强、修复、上色和抠图的在线 AI 工具平台。

下载

不同数据库对 CTE + DELETE 的支持有差异

SQL Server 和 PostgreSQL 支持 DELETE FROM cte_name；MySQL 8.0+ 也支持，但 MySQL 5.7 及更早版本不支持，得改用 JOIN 方式。

SQL Server / PostgreSQL：DELETE FROM dupes WHERE rn > 1（CTE 名直接用于 DELETE）
MySQL 8.0+：DELETE t1 FROM users t1 INNER JOIN dupes t2 ON t1.id = t2.id WHERE t2.rn > 1
SQLite：不支持窗口函数，无法用此方案，需改用自连接或临时表

执行前查清自己用的数据库版本，别在 MySQL 5.7 上硬套 PostgreSQL 写法，否则报错 ERROR 1288: The target table dupes of the DELETE is not updatable。

性能和索引影响不能忽视

ROW_NUMBER() 在大数据量下会触发全表扫描和排序，如果没索引，几百万行可能卡住十几秒甚至超时。关键点在于 PARTITION BY 和 ORDER BY 字段的联合索引。

理想索引：CREATE INDEX idx_users_dup_check ON users (email, user_id, updated_at)（顺序要匹配 PARTITION + ORDER）
没有索引时，ROW_NUMBER() OVER (PARTITION BY a,b ORDER BY c) 可能比单列 ORDER BY c 慢数倍
删重后记得 VACUUM（PostgreSQL）或 UPDATE STATISTICS（SQL Server），避免后续查询走错执行计划

真正麻烦的不是语法怎么写，而是想清楚“重复”的定义是否稳定、分区字段有没有隐含 NULL 值（NULL 不参与 PARTITION BY 分组，会导致意外漏分）、以及删完要不要重建唯一约束——这些细节比函数本身更容易出问题。