MySQL禁止在DELETE中直接子查询同一张表，因语义限制“不能一边读一边删”；需用派生表（如SELECT ... FROM (...) AS tmp）或自连接（如DELETE t1 FROM t1 JOIN t2 ON ...）绕过ERROR 1093。
为什么直接用子查询删重复数据会报错
MySQL 会拒绝执行类似 DELETE FROM t WHERE id IN (SELECT id FROM t GROUP BY name HAVING COUNT(*) > 1) 这样的语句，报错 You can't specify target table 't' for update in FROM clause。这不是语法写错了，而是 MySQL 的限制：不能在同一个 SQL 中对同一张表既查又删。PostgreSQL 和 SQL Server 没这限制，但 MySQL 用户得绕开它。
用 JOIN 替代子查询是最稳的写法
核心思路是把子查询结果“抽出来”，变成一个临时中间集，再跟原表做 JOIN 删除。实际操作中，用自连接或派生表都行，但派生表更清晰、兼容性更好。
假设表 users 有字段 id、email，要按 email 去重，只保留每组 id 最小的记录：
DELETE u1 FROM users u1 INNER JOIN users u2 ON u1.email = u2.email AND u1.id > u2.id;
这个写法不触发 MySQL 的限制，因为 u1 和 u2 被视为两个逻辑表。关键点：
-
u1.id > u2.id确保只删“更大 ID”的行，留下最小 ID - 必须加
ON条件中的等值匹配（如u1.email = u2.email），否则会误删 - 没加
WHERE也行，但建议加上WHERE u2.id IS NOT NULL防空关联（虽通常不影响）
用派生表 + LIMIT 1 控制保留哪一条
如果要保留最新（最大 ID）而非最老的记录，或者去重依据不止一列（比如 (email, status)），用派生表更灵活：
DELETE FROM users
WHERE id NOT IN (
SELECT id FROM (
SELECT MIN(id) AS id
FROM users
GROUP BY email
) AS keep
);注意这里套了一层 SELECT ... FROM (...)，就是为了骗过 MySQL 的检查。但有坑：
- 如果某组
email对应的所有id都为NULL，NOT IN会失效（NULL 不参与比较），得额外处理 -
GROUP BY字段如果有 NULL，MySQL 默认把它们归为一组，但行为可能因 SQL mode 而异 - 大数据量时，
NOT IN子查询性能差，建议给email加索引
删之前必须做的三件事
删重复数据不是写完就跑的活，尤其在线上表：
- 先用
SELECT模拟删什么：SELECT * FROM users u1 INNER JOIN users u2 ON u1.email = u2.email AND u1.id > u2.id; - 确认主键/唯一约束是否允许你删——比如外键引用了这些行，得先处理依赖
- 务必在事务里操作：
BEGIN; DELETE ... ; SELECT ROW_COUNT(); ROLLBACK;测完再COMMIT
最容易被忽略的是：没有检查业务逻辑是否依赖“重复项”本身。比如某些日志表靠重复插入标记状态变更，盲目去重可能让下游解析出错。
