MySQL 5.7中直接用DELETE...IN(SELECT...)删重复数据会报错“1093”，因禁止对目标表自引用；须用SELECT * FROM (子查询) AS tmp包装成派生表绕过限制，再配合NOT IN保留每组最小id记录。
用 IN 子查询定位要删的重复行 ID
直接用 DELETE ... IN (SELECT ...) 删除重复数据，MySQL 会报错 You can't specify target table 'xxx' for update in FROM clause——它不允许多重引用同一张表。绕过这问题的核心思路是：把子查询结果“隔一层”再喂给外层 IN。
假设表 users 有字段 email，需按 email 去重，只保留每组中 id 最小的记录：
DELETE FROM users
WHERE id NOT IN (
SELECT * FROM (
SELECT MIN(id)
FROM users
GROUP BY email
) AS tmp
);-
SELECT MIN(id) ... GROUP BY email找出每个邮箱对应最小的id - 外层再套一层
SELECT * FROM (...) AS tmp，让 MySQL 把结果当临时表处理，避开“不能查自己”的限制 -
NOT IN确保只删掉非“最小 ID”的重复行
为什么不能直接写 IN (SELECT MIN(id) FROM users GROUP BY email)
因为 MySQL 在执行时会把子查询和外层 DELETE 视为对同一张表的并发访问，触发内部锁机制保护，直接拒绝。PostgreSQL 和 SQL Server 没这限制，但 MySQL（尤其 5.7 及以前）必须加中间层包装。
常见错误写法及现象：
-
DELETE FROM users WHERE id NOT IN (SELECT MIN(id) FROM users GROUP BY email);→ 报错You can't specify target table... - 漏掉
AS tmp别名 → MySQL 8.0+ 仍报错，提示Every derived table must have its own alias - 没加
NOT IN，误写成IN→ 删掉的是“唯一行”，留下所有重复行
实际删除前务必先验证子查询结果
删库跑路第一步永远是“先看要删啥”。别跳过这步，尤其是生产环境。
- 先跑内层查询确认逻辑：
SELECT email, COUNT(*), MIN(id), MAX(id) FROM users GROUP BY email HAVING COUNT(*) > 1;查出哪些邮箱真有重复、各有多少条、ID 范围 - 再跑最终用于删除的 ID 列表：
SELECT * FROM (SELECT MIN(id) FROM users GROUP BY email) AS tmp;看输出是否符合预期 - 如果表很大，
GROUP BY可能慢，确保email字段有索引，否则全表扫描 + 临时文件排序会卡住
替代方案：用 JOIN 比 IN 更稳定且易读
虽然问题明确要求用 IN 子查询，但真实场景中，LEFT JOIN 或 JOIN 方式更可靠，也更容易调试：
DELETE u1 FROM users u1 LEFT JOIN ( SELECT email, MIN(id) AS min_id FROM users GROUP BY email ) u2 ON u1.email = u2.email AND u1.id = u2.min_id WHERE u2.min_id IS NULL;
这个写法不依赖子查询嵌套层数，语义清晰：找所有“找不到对应最小 ID”的行来删。性能上通常比多层 IN 更好，特别是当重复组很多、MIN(id) 结果集较大时。
真正容易被忽略的是：删完后记得检查 AUTO_INCREMENT 值是否异常，以及是否需要重建索引——大量删除可能造成页碎片，影响后续插入性能。
