千万级数据去重不能用DELETE...WHERE id NOT IN(...)，因MySQL 8.0前不支持同表读写、NOT IN遇NULL失效、易全表扫描和日志暴涨；推荐临时表三步法：建新表、INSERT SELECT GROUP BY去重、RENAME原子替换，并加唯一索引防复。
千万级数据直接 DELETE 去重大概率会锁表、OOM 或超时，必须绕开逐行操作；临时表 + 唯一索引是目前最稳的组合方案。
为什么不能用 DELETE ... WHERE id NOT IN (SELECT ...) 直接删
MySQL 8.0 以前不支持对同一张表在子查询中同时读写，即使加了 AS t 封装，面对千万行也极易触发临时表溢出或磁盘排序；更关键的是，NOT IN 遇到 NULL 会整体失效，导致漏删。线上环境一旦执行卡住，KILL 可能引发长时间回滚，影响其他业务。
-
NOT IN子查询结果含NULL→ 整个条件恒为FALSE，一条都不删 - 子查询未走索引 →
EXPLAIN显示type=ALL，全表扫描两次 - 大事务日志暴涨 →
binlog和innodb_log_file_size压力陡增
用临时表重建：三步完成去重（推荐）
核心思路是“先选再建再换”，全程避免原表 DML 锁，且可中断重试。适用于 id 不是业务主键、允许重建表结构的场景。
- 创建空新表：
CREATE TABLE users_clean LIKE users;（保留原表所有字段、类型、默认值） - 插入去重数据：
INSERT INTO users_clean SELECT * FROM (SELECT MIN(id) AS id, email, name FROM users GROUP BY email) AS tmp;（注意：若需保留最新记录，把MIN(id)换成MAX(id)） - 原子替换：
RENAME TABLE users TO users_bak, users_clean TO users;（毫秒级完成，无业务感知）
⚠️ 注意：如果原表有外键，RENAME 会失败，需先 DROP FOREIGN KEY，重建后再加回。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
加唯一索引防止二次重复
重建后立刻执行 ALTER TABLE users ADD UNIQUE INDEX idx_email (email);，否则下次导入又会堆积重复。但这里有两个现实约束：
- 如果
email允许为NULL，MySQL 会把多个NULL当作不同值，不触发唯一冲突 → 解决办法是加WHERE email IS NOT NULL过滤，或改用COALESCE(email, CONCAT('null_', id))虚拟值 - 联合唯一索引如
(user_id, order_time)，要确认业务是否真需要“同一用户同秒下单只允一次”，否则可能误拦合法数据 - 添加索引过程会锁表（MySQL 5.6+ 支持
ALGORITHM=INPLACE，但仍需元数据锁等待）→ 建议在低峰期执行
临时表方案的隐藏成本你得知道
它快，但不是零代价：临时表本身要占磁盘空间（约等于原表大小），且 GROUP BY 阶段若没索引，仍会触发 Using temporary; Using filesort。所以真正高效的前提是——
- 确保
GROUP BY字段上有合适索引，例如CREATE INDEX idx_email ON users(email); - 如果去重依据是多列（如
(country, city, postal_code)），必须建联合索引，单列索引无效 -
SELECT *从子查询取值时，非GROUP BY字段（如name）实际取的是组内任意一行，MySQL 不保证是MIN(id)那行 → 必须显式写MIN(id), email, MAX(name)等聚合逻辑
最后提醒一句：别省略 RENAME 前的备份步骤，RENAME TABLE users TO users_bak 这一步花不了几秒，但能救你整个上线窗口。
