row_number()不能直接删除重复行，因其仅为查询时生成的临时序号，不持久化存储，且sql标准禁止在delete的where子句中直接使用窗口函数；必须通过cte或子查询先标记再删除。
ROW_NUMBER() 为什么不能直接物理删除重复行
因为 ROW_NUMBER() 是窗口函数，只在查询时生成临时序号，不改变表结构或存储状态。你执行 SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t 看到的 rn 列根本不存在于磁盘上，自然无法用它驱动 DELETE —— SQL 标准里不允许在 DELETE 的 WHERE 子句中直接嵌套带窗口函数的子查询（多数数据库会报错，如 PostgreSQL 提示“window functions are not allowed in WHERE”，MySQL 8.0+ 虽支持 CTE 中用窗口函数，但仍不能直接删）。
用 CTE + ROW_NUMBER() 实现安全去重删除（PostgreSQL / SQL Server / MySQL 8.0+）
真正可行的做法是：先把要保留的行（比如每组重复中 rn = 1 的那条）找出来，再反向删掉其余行。核心靠可更新的 CTE 或派生表配合主键/唯一标识。
假设表 users 中 (name, email) 重复，且有主键 id：
WITH dupes AS (
SELECT id,
ROW_NUMBER() OVER (
PARTITION BY name, email
ORDER BY id
) AS rn
FROM users
)
DELETE FROM users
WHERE id IN (
SELECT id FROM dupes WHERE rn > 1
);
- 必须确保
PARTITION BY列能准确表达“重复逻辑”，ORDER BY决定哪条被保留（例如按created_at DESC保留最新记录） - MySQL 8.0+ 支持上述写法；PostgreSQL 要求 CTE 后的
DELETE显式关联目标表，可改用：DELETE FROM users USING dupes WHERE users.id = dupes.id AND dupes.rn > 1 - SQL Server 允许直接
DELETE FROM (CTE)，但需 CTE 包含所有被删表的列（实际常用DELETE t FROM users t INNER JOIN dupes d ON t.id = d.id WHERE d.rn > 1）
没有主键时的危险操作与替代方案
如果表既无主键也无唯一约束（比如日志表、ETL 中间表），ROW_NUMBER() 仍可编号，但无法安全定位并删除特定行——因为多行完全相同，删哪条都不可控，甚至可能误删全部。
- 先用
SELECT DISTINCT或GROUP BY验证重复模式：SELECT name, email, COUNT(*) FROM users GROUP BY name, email HAVING COUNT(*) > 1 - 若必须删，建议先导出清洗后数据重建表：
CREATE TABLE users_clean AS SELECT DISTINCT * FROM users;，再重命名切换（注意外键、索引、权限需手动迁移） - 某些数据库（如 PostgreSQL）支持
ctid伪列临时定位物理行：DELETE FROM users WHERE ctid NOT IN (SELECT MIN(ctid) FROM users GROUP BY name, email)，但这属于实现细节，跨版本不兼容，生产环境慎用
性能和事务风险提醒
大表上执行这类删除容易锁表、打满 WAL、触发 autovacuum 压力，尤其当重复率低但总行数巨大时，IN (subquery) 可能走嵌套循环，比预期慢几个数量级。
- 务必在非高峰时段操作，并限制每次删 1 万行以内，用
LIMIT（PostgreSQL/MySQL）或TOP（SQL Server）分批，配合WHERE id BETWEEN ...更稳 - 提前建好
PARTITION BY字段的复合索引，加速窗口函数排序和后续关联 - 执行前先
BEGIN; SELECT COUNT(*) FROM (...) AS dupes WHERE rn > 1;预估影响行数，避免误删整个表
真正麻烦的从来不是写对 ROW_NUMBER()，而是确认“哪些算重复”“哪条该留下”“删完业务逻辑是否还成立”——这些没法靠函数自动判断。
