row_number()本身不直接去重，需配合partition by分组、order by排序（如created_at desc, id desc）编号，再用where rn=1或delete筛选保留每组首行。
用 ROW_NUMBER() 窗口函数标记重复行
SQL 没有“直接去重留最新”这种原子操作，必须靠排序+编号+过滤组合实现。核心思路是：按业务主键分组，按时间字段（如 created_at 或 id）倒序排，给每组第一行标上 1，其余标更大数字，再删掉所有非 1 的行。
常见错误是只用 GROUP BY 配合 MAX(id) 做子查询——它能拿到最大 id，但无法保证其他字段（比如 status、updated_at）和该 id 对应，结果可能拼出根本不存在的脏记录。
实操建议：
- 确保用于判断“最新”的字段（如
updated_at）有索引，否则ORDER BY ... DESC在大表上极慢 - 分组字段必须是真正定义“重复”的列，比如
(user_id, order_type)，而不是只写user_id - 如果时间字段允许 NULL，
ORDER BY updated_at DESC会把 NULL 排最前，需显式写成ORDER BY updated_at DESC NULLS LAST（PostgreSQL 支持；MySQL/SQL Server 默认忽略 NULL 位置）
DELETE + CTE 或子查询的实际写法
不同数据库语法略有差异，但逻辑一致：先在 CTE 或内层查询中算出每组的行号，外层删掉 row_num > 1 的行。
PostgreSQL / SQL Server / Oracle（支持 CTE）：
WITH ranked AS (
SELECT id, user_id, updated_at,
ROW_NUMBER() OVER (
PARTITION BY user_id, order_type
ORDER BY updated_at DESC, id DESC
) AS row_num
FROM orders
)
DELETE FROM orders
WHERE id IN (
SELECT id FROM ranked WHERE row_num > 1
);
MySQL 8.0+ 同样可用 CTE；若用 MySQL 5.7，则必须改用 JOIN 子查询：
DELETE o1 FROM orders o1
INNER JOIN orders o2
ON o1.user_id = o2.user_id
AND o1.order_type = o2.order_type
AND (
o1.updated_at <p>注意点：</p>
-
DELETE ... USING（PostgreSQL）或DELETE ... JOIN（MySQL）不支持直接引用窗口函数，所以必须套一层 - 多重排序条件（如
updated_at DESC, id DESC）是为了在时间相同时有确定性，避免因排序不稳定导致删错 - 删前务必先用
SELECT *把 CTE 中row_num > 1的数据查出来人工核对
没有主键或时间字段时怎么处理
如果表既无自增 id 也无 created_at，仅靠业务字段（如 email、phone）重复，那就无法定义“最新”，只能留任意一条——此时目标变成“去重留一行”，而非“留最新”。
可行做法是用 MIN(id) 或 MAX(id) 当锚点：
DELETE FROM users WHERE id NOT IN ( SELECT MIN(id) FROM users GROUP BY email, phone );
但要注意：
- 这种写法在 MySQL 中可能报错
You can't specify target table for update in FROM clause，需再套一层子查询 -
GROUP BY字段必须和去重逻辑完全一致，漏一个就可能多留重复 - 如果根本没有数值型唯一标识（比如只有文本字段），就得靠临时添加自增列或导出后用脚本处理，SQL 本身已无可靠手段
实际执行前，一定先备份或在事务里测试：
BEGIN; -- 先看要删哪些 SELECT * FROM ranked WHERE row_num > 1 LIMIT 10; -- 再删 DELETE FROM orders WHERE id IN (SELECT id FROM ranked WHERE row_num > 1); -- 检查 SELECT user_id, order_type, COUNT(*) FROM orders GROUP BY user_id, order_type HAVING COUNT(*) > 1; ROLLBACK; -- 确认无误再 COMMIT
最易被忽略的是：时间字段精度不足（比如只到秒）、或应用写入时未严格更新 updated_at，会导致“最新”判断失效。这种问题不会报错，但删完数据逻辑就错了。
