ROW_NUMBER()能精准定位重复行，因其为每行分配严格递增唯一序号，而COUNT(*)OVER仅统计数量、RANK/DENSE_RANK对相同值并列编号；它不可直接用于DELETE因SQL标准禁止窗口函数出现在WHERE子句中，须通过CTE或子查询结合主键与PARTITION BY+ORDER BY实现安全去重。
ROW_NUMBER() 为什么能精准定位重复行
因为它是唯一能给“相同值组合”的每一行分配严格递增序号的窗口函数，而其他聚合或排名函数做不到这点。比如 COUNT(*) OVER 只告诉你是第几组、共几条，但不区分组内哪一行该留；DENSE_RANK() 对相同值给相同编号，无法标记“第二条、第三条”——只有 ROW_NUMBER() 能让每条重复数据拥有确定且唯一的序号。
DELETE 不能直接套 ROW_NUMBER() 的真实原因
多数数据库（PostgreSQL、SQL Server、Oracle）在语法层禁止窗口函数出现在 DELETE 的 WHERE 或子查询中，硬写会报错：ERROR: window functions are not allowed in DELETE。这不是功能缺失，而是 SQL 标准为避免歧义做的限制：删除操作必须基于可明确寻址的行（如主键、ctid），不能依赖动态计算的窗口结果。
-
ROW_NUMBER()必须包裹在 CTE 或子查询里，生成一个带序号的临时结果集 - 这个临时结果集必须包含原表的唯一标识字段（如
id或ctid），否则DELETE无法安全关联到真实行 - MySQL 8.0+ 允许
DELETE FROM t1 JOIN (CTE) t2，但 PostgreSQL 必须用DELETE FROM t USING cte或WHERE id IN (SELECT id)
PARTITION BY 和 ORDER BY 决定删得对不对
漏字段、错排序，删出来的结果就不可控。比如按 email 去重，但实际业务要求 name 和 email 都相同才算重复，那 PARTITION BY email 就会误删不同 name 的用户。
-
PARTITION BY字段必须和你定义“重复”的业务逻辑完全一致，少一个字段 = 多删，多一个字段 = 漏删 -
ORDER BY不是可选项：它决定rn = 1是哪一条。想留最新插入的，就得ORDER BY created_at DESC；想留主键最小的，就得ORDER BY id ASC - 某些数据库（如 SQL Server）强制要求
ORDER BY存在，哪怕只是ORDER BY (SELECT NULL)，否则语法报错
为什么推荐 CTE + 子查询而不是 GROUP BY + MIN(id)
因为 GROUP BY + MIN(id) 写法虽然简洁，但它隐式假设“最小 id 就是该保留的行”，一旦表里有软删除标记、历史归档或主键非单调插入（比如 UUID 主键），这条假设就崩了。而 ROW_NUMBER() 的 ORDER BY 可以显式绑定业务字段（如时间戳、状态优先级），更可控。
-
DELETE FROM users WHERE id NOT IN (SELECT MIN(id) FROM users GROUP BY email)看似简单，但无法应对“保留最新更新时间”的需求 - CTE 方案天然支持多字段去重、灵活排序、分步验证（先
SELECT *看rn > 1的行是否符合预期） - 大表执行前没索引？
PARTITION BY字段缺失索引会导致全表扫描，耗时飙升——这点容易被忽略，但比写错 SQL 更致命
