MySQL去重推荐用自连接DELETE（保留最小ID）或临时表重建（兼容性好），8.0+可用ROW_NUMBER()精准控制保留逻辑，执行前须校验外键、safe_updates及重复判定标准。
用自连接 DELETE 语句直接去重（MySQL 5.7+ 支持）
MySQL 不支持在 DELETE 中直接引用被删表的别名用于子查询，但允许用自连接语法绕过限制。关键点是：用 JOIN 关联同一张表，通过比较主键或唯一字段，只删掉“更大 ID”的重复行。
假设表 users 有字段 email 需去重，保留最小 id 的那条：
DELETE u1 FROM users u1 INNER JOIN users u2 WHERE u1.email = u2.email AND u1.id > u2.id;
常见错误现象：ERROR 1093 (HY000): You can't specify target table 'u1' for update in FROM clause —— 这说明你误用了子查询写法（如 DELETE FROM ... WHERE id IN (SELECT ...)），必须改用自连接。
- 务必确保
email字段有索引，否则 JOIN 会全表扫描，大表可能卡死 -
u1.id > u2.id是保留最小 ID 的核心逻辑；若想保留最大 ID，改成u1.id - 执行前先用
SELECT验证哪些行会被删：SELECT u1.* FROM users u1 INNER JOIN users u2 WHERE u1.email = u2.email AND u1.id > u2.id;
用临时表重建去重（兼容所有 MySQL 版本，适合大表或复杂条件）
当重复逻辑涉及多个字段、或需按时间/状态优先保留某条时，临时表方案更可控。本质是把去重后的数据导出到新表，再替换原表。
步骤分三步，注意顺序不能错：
- 创建结构相同的新表：
CREATE TABLE users_dedup LIKE users; - 用
INSERT ... SELECT ... GROUP BY或ROW_NUMBER()（MySQL 8.0+）插入去重后数据。例如 5.7 下常用：INSERT INTO users_dedup SELECT MIN(id) AS id, email, name, created_at FROM users GROUP BY email;
- 原子性替换：
DROP TABLE users; RENAME TABLE users_dedup TO users;（生产环境建议先备份原表）
性能影响：GROUP BY 在无索引字段上会触发 filesort；若 email 无索引，先加 ALTER TABLE users ADD INDEX idx_email (email); 再操作。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
MySQL 8.0+ 推荐用 ROW_NUMBER() 精确控制保留逻辑
当需要按业务规则保留特定行（比如保留最新更新的、或 status=1 的），ROW_NUMBER() 比 GROUP BY 更灵活，且避免聚合丢失字段值。
示例：按 email 分组，按 updated_at DESC 排序，只留每组第一行：
DELETE t FROM users t
INNER JOIN (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY updated_at DESC) AS rn
FROM users
) ranked ON t.id = ranked.id
WHERE ranked.rn > 1;
容易踩的坑：
-
ROW_NUMBER()必须配合OVER子句，漏写括号或PARTITION BY会报语法错误 - 窗口函数不能直接用于 DELETE 的 WHERE，必须包一层子查询关联
- 排序字段含 NULL 时，
ORDER BY updated_at DESC会让 NULL 排最前；需加NULLS LAST（MySQL 8.0.22+）或用IFNULL(updated_at, '1970-01-01')替代
执行前必须检查的三个底层事实
很多去重失败不是语法问题，而是忽略了表本身的状态：
- 确认没有外键约束指向该表 —— 否则
DROP TABLE或DELETE会报错；可用SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users';检查 - 检查是否启用了
safe_updates模式（默认 ON），它会拒绝没带 WHERE 的 DELETE；临时关闭：SET SQL_SAFE_UPDATES = 0;，执行完记得恢复 - 重复判定标准是否真能覆盖全部场景？比如
email字段前后空格、大小写不敏感（utf8mb4_0900_as_cs校对集才区分大小写），建议先跑SELECT email, COUNT(*) FROM users GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1;
真正麻烦的从来不是写哪条 DELETE，而是搞清“什么是重复”以及“哪一条才算‘该留的’”。校验逻辑比执行动作花的时间多得多。
