MySQL中DELETE不能直接使用ROW_NUMBER()，因窗口函数禁用于WHERE子句且禁止同一语句中读写同表；必须用CTE或子查询包装后JOIN删除，ORDER BY决定保留行，操作前需验证、备份并确保索引与版本支持。
必须用子查询或CTE包装ROW_NUMBER()结果，再关联删除；直接在DELETE中写窗口函数会报错，且ORDER BY方向决定哪条数据被保留。
为什么DELETE里不能直接用ROW_NUMBER()
MySQL不允许在DELETE语句的WHERE子句中直接调用窗口函数，会报错Window function is not allowed in WHERE clause。更关键的是，即使绕过语法检查，也无法在同一个语句中对同一张表既查又删——执行DELETE FROM t WHERE id IN (SELECT id FROM t ... ROW_NUMBER() ...)会触发Error 1093: You can't specify target table 't' for update in FROM clause。
解决路径只有一条：把带ROW_NUMBER()的结果当临时结果集（派生表或CTE），再让外层DELETE通过JOIN或IN引用它。
- CTE写法更清晰，但仅MySQL 8.0.1+支持，且需注意语法：MySQL不支持
DELETE FROM tbl USING cte那种PostgreSQL风格，得用DELETE t1 FROM t1 JOIN cte ON ... - 子查询写法兼容性更好，但嵌套两层是硬性要求：内层算
rn，中层筛选rn > 1，外层执行删除 - 别信“加了
GROUP BY就能删”的简化写法，那只是去重逻辑错觉，实际无法保证字段完整性
ORDER BY怎么写才真正控制“留哪一条”
ORDER BY不是为了好看，它直接决定ROW_NUMBER() = 1落在哪一行。比如PARTITION BY email ORDER BY created_at DESC会让最新时间的记录排第一，从而被保留；反过来写ASC就留下最老的一条。
常见踩坑点：
- 用
id排序时，默认ASC会留最小ID，但若业务要留最新插入的，而ID又不是自增主键（比如UUID或业务生成ID），结果就不可控 - 字段含
NULL时，MySQL 8.0.22+才支持ORDER BY col DESC NULLS LAST，旧版默认把NULL排最前，可能误删本该保留的记录 - 多条件优先级不能靠多个
ORDER BY字段堆砌，得用CASE表达式量化权重，例如优先保留status = 'active'，再按时间降序：ORDER BY CASE WHEN status = 'active' THEN 0 ELSE 1 END, created_at DESC
删除前必须验证和备份的实操动作
执行DELETE前不验证等于闭眼开车。先跑一遍等价的SELECT语句，确认哪些ID会被删：
SELECT id, email, created_at,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS rn
FROM users
WHERE rn > 1;但注意：上面这句会报错，因为WHERE rn > 1不能直接用别名。正确预览写法是：
SELECT * FROM (
SELECT id, email, created_at,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS rn
FROM users
) t WHERE rn > 1;- 务必先执行
CREATE TABLE users_backup AS SELECT * FROM users;，尤其当表无主键或PARTITION BY字段有大量NULL时，误删风险极高 - 大表操作建议套事务：
BEGIN; DELETE ... ; SELECT ROW_COUNT(); ROLLBACK;，确认行数合理再COMMIT - 如果
PARTITION BY字段没索引，ROW_NUMBER()计算会全表扫描，100万行以上可能卡住，删之前先加复合索引，如ALTER TABLE users ADD INDEX idx_email_time (email, created_at);
低版本MySQL（如5.7）根本不能用ROW_NUMBER()
执行SELECT VERSION();确认版本号≥8.0.2，否则会报错FUNCTION yourdb.ROW_NUMBER does not exist。5.7及更早版本只能换方案：
- 用自连接：
DELETE t1 FROM users t1 INNER JOIN users t2 ON t1.email = t2.email AND t1.id > t2.id;——小表可用，大数据量易锁表、慢 - 用临时表导出再导入，适合一次性清理且能停服的场景
- 用应用层分批拉取+去重+回写，适合需要复杂业务判断的场景
窗口函数不是银弹，它只解决“按明确规则留一条”的问题；如果重复行之间差异极小、或保留逻辑依赖外部状态（比如要查另一张表判断是否激活），就得跳出SQL，用程序逻辑兜底。
