是的，mysql 中 delete 语句不能直接在子查询中引用目标表，会报 error 1093；需用 join 自连接或嵌套派生表（如 select ... from (select ... from t) as tmp）绕过限制。
DELETE 语句里不能直接用子查询引用目标表？
是的，MySQL 会报错 ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是语法写错了，而是 MySQL 的限制：在同一个语句中，不能对一张表既查又删（或更新）。PostgreSQL 和 SQL Server 没这限制，但 MySQL 用户占多数，得绕开它。
常见错误写法：
DELETE FROM users WHERE id NOT IN (SELECT MIN(id) FROM users GROUP BY email);——这条在 MySQL 直接报错。
- 临时起个别名不解决根本问题，
FROM users t1+WHERE id NOT IN (SELECT ... FROM users)还是不行 - 真正有效的解法是把子查询结果“包一层”，让它变成派生表（derived table）
- 或者改用
JOIN写法，更直观也更易调试
用 JOIN 删除重复行（推荐 MySQL 场景）
核心思路：把原表自连接，让“保留的那条”和“要删的那条”形成关联关系。比如按 email 去重，只留 id 最小的那条，其余都删。
实操语句：
DELETE u1 FROM users u1 INNER JOIN users u2 WHERE u1.email = u2.email AND u1.id > u2.id;
-
u1是待删除的目标；u2是用来做参照的副本 -
u1.id > u2.id确保只删“更大 ID”的重复行，留下最小 ID 的那条 - 务必加
WHERE条件限定连接逻辑，否则可能误删整张表 - 执行前先用
SELECT u1.*替换DELETE u1预览将删哪些行
用派生表绕过 MySQL 1093 错误
如果坚持用子查询风格（比如习惯性用 NOT IN），必须让子查询变成不可被 MySQL 识别为“同一张表”的结构。
正确写法：
DELETE FROM users WHERE id NOT IN (SELECT min_id FROM (SELECT MIN(id) AS min_id FROM users GROUP BY email) AS tmp);
- 最内层
SELECT MIN(id) ... GROUP BY email生成去重后的最小 ID 列表 - 中间套一层
SELECT min_id FROM (...) AS tmp，这个AS tmp是关键——它强制 MySQL 把结果当临时表处理 - 外层
NOT IN就不再触犯 1093 限制 - 注意：如果
email字段允许 NULL，NOT IN会失效（NULL 不参与比较），此时必须补OR email IS NULL或改用NOT EXISTS
WHERE 条件漏写或写错导致全表误删
这是真实发生过的线上事故高频原因。DELETE 没有 WHERE 就是删全表；WHERE 条件没覆盖好，也可能只删部分重复但漏掉另一批。
- 永远先跑
SELECT验证逻辑，例如：SELECT u1.* FROM users u1 INNER JOIN users u2 WHERE u1.email = u2.email AND u1.id > u2.id; - 确认数据量合理（比如预期删 127 行，结果预览出 5 万行，立刻停手）
- 涉及多字段去重（如
(email, phone)联合唯一）时，JOIN 或 GROUP BY 的字段必须完全一致，少一个就失效 - 大表操作建议加索引：
ALTER TABLE users ADD INDEX idx_email_id (email, id);，否则 JOIN 可能慢到超时甚至锁表
最麻烦的不是语法怎么写，而是删之前没想清楚“哪条该留、哪条该删”。尤其是业务上存在“最新数据优先保留”而非“ID 最小优先”的场景，MIN(id) 就不适用了，得换成 MAX(created_at) 并配合排序取首行——这时候子查询嵌套更深，更得靠预览和索引兜底。
