MySQL中DELETE...EXISTS可行但需满足相关子查询前提，否则报错或误删；自关联删除需用派生表或分步处理，且须注意NULL、索引及关联条件完整性。
MySQL 中直接用 DELETE ... WHERE EXISTS 是完全可行的，但必须满足“相关子查询”这个关键前提——否则语句会报错或逻辑错乱。
DELETE + EXISTS 为什么有时“走不通”
常见失败不是语法不支持，而是子查询没和外部表建立关联。比如删掉 folder 表中重复的 code 记录时写成：
DELETE FROM folder fd1 WHERE EXISTS (SELECT 1 FROM folder fd2 WHERE fd2.code = fd1.code AND fd2.id <> fd1.id);
这看起来没问题，但 MySQL 8.0.19+ 之前版本会报错 You can't specify target table 'fd1' for update in FROM clause——因为子查询里直接引用了正被删除的同一张表。
- 这是 MySQL 的限制，不是 EXISTS 本身的问题
- 子查询里若漏写
fd2.id fd1.id这类关联条件，会导致恒真（每行都匹配自己），全表被误删 - 即使语法通过，没加索引时，
EXISTS子查询可能对每行都扫一遍folder，性能崩盘
正确写法：用别名 + 显式关联 + 避免自引用
真正安全、可执行的模式是让子查询“只读”，且明确依赖外部行。例如删除没有订单的客户：
DELETE FROM customers WHERE NOT EXISTS (SELECT 1 FROM orders WHERE orders.customer_id = customers.id);
这里 customers 是主表，orders 是子查询里的只读表，不存在自引用问题。
- 子查询中的
orders.customer_id = customers.id是必须的关联条件，缺了就变成非相关子查询 - 用
NOT EXISTS比LEFT JOIN ... IS NULL更清晰，也更容易命中索引 - 确保
orders.customer_id上有索引，否则子查询每次都要全表扫描orders
处理“自关联删除”（如去重）的替代方案
当你要基于同一张表判断重复并删除时，DELETE ... EXISTS 直接写会撞上 MySQL 的限制。这时得绕开：
- 用派生表（derived table）包裹子查询：
DELETE f1 FROM folder f1 WHERE EXISTS (SELECT 1 FROM (SELECT code FROM folder GROUP BY code HAVING COUNT(*) > 1) dup WHERE dup.code = f1.code) AND f1.id NOT IN (SELECT MIN(id) FROM folder GROUP BY code);
- 更稳妥的做法是分两步：先查出要保留的 ID（如每个
code的最小id），再删掉不在这个集合里的行：DELETE FROM folder WHERE id NOT IN (SELECT min_id FROM (SELECT MIN(id) AS min_id FROM folder GROUP BY code) AS t);
- 注意：子查询外层必须套一层
AS t别名，否则 MySQL 报错This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'
容易被忽略的坑：NULL 和索引
EXISTS 对 NULL 安全，但你的关联字段如果允许 NULL，结果可能不符合直觉。比如 orders.customer_id 是 NULL，那 orders.customer_id = customers.id 永远不成立，这些客户会被当成“无订单”误删。
- 检查关联字段是否为
NOT NULL，如果不是，加额外判断：AND orders.customer_id IS NOT NULL -
EXISTS的性能高度依赖子查询中 WHERE 条件字段的索引。没索引时，哪怕只删 1 行，也可能触发对子表的 N 次全表扫描 - 用
EXPLAIN看执行计划，确认子查询走了索引（type字段显示ref或eq_ref，而非ALL）
最麻烦的从来不是语法写不对，而是删之前没想清楚“哪一行该被判定为存在/不存在”——尤其是关联字段含 NULL、索引缺失、或需要跨表多层判断时，EXISTS 的行为很容易偏离预期。
