not exists 比 left join 更安全，因其天然规避多对一场景下因重复匹配导致的误删风险；它通过存在性判断精准识别孤立记录，且不受 null 值影响，而 left join ... is null 在外键非唯一时可能因结果集膨胀使判断失准。
DELETE WHERE NOT EXISTS 为什么比 LEFT JOIN 更安全？
直接用 DELETE 配合 NOT EXISTS 是清理“在 A 表存在、但在 B 表找不到对应记录”的冗余数据最稳妥的方式。它天然规避了 LEFT JOIN ... IS NULL 在多对一场景下的误删风险——比如 B 表里某条主键被多个外键引用，LEFT JOIN 可能因重复行导致子查询结果集膨胀，让 IS NULL 判断失准。
实操建议：
-
NOT EXISTS子查询必须关联主键或唯一约束字段，否则可能漏判；例如 A 表的user_id对应 B 表的id，子查询里写WHERE b.id = a.user_id - 子查询中不要 SELECT *，只写
SELECT 1即可，语义清晰且数据库优化器更容易识别为半连接（semi-join） - 务必先用
SELECT验证子查询逻辑：把DELETE FROM a换成SELECT * FROM a，确认返回的确实是你要删的那些行
MySQL 中 DELETE + JOIN 的语法陷阱
MySQL 支持 DELETE t1 FROM table1 t1 JOIN table2 t2 ON ... 写法，但不支持标准 SQL 的 DELETE FROM t1 USING ... 或直接 DELETE FROM t1 JOIN t2。如果写错语法，会报错 You can't specify target table 't1' for update in FROM clause——这是 MySQL 对同一张表既读又写的限制。
常见错误现象：
- 想用
DELETE FROM a WHERE id NOT IN (SELECT a_id FROM b)，但 B 表有NULL值，导致整个NOT IN判定为UNKNOWN，一行都不删 - 用
DELETE a FROM a LEFT JOIN b ON a.id = b.a_id WHERE b.a_id IS NULL，看似合理，但如果 B 表里a_id不是唯一键，一条 A 记录可能匹配多条 B 记录，实际只删一次（行为正确），但执行计划可能更重 - 没加
WHERE条件直接跑DELETE FROM a JOIN b ...，删掉的是笛卡尔积结果，不是预期的差集
PostgreSQL 和 SQL Server 怎么写才不出错？
PostgreSQL 不允许在 DELETE 的 FROM 子句里直接写多表，必须用 USING；SQL Server 则支持 DELETE t FROM t JOIN s ON ...，但别名必须出现在 DELETE 后面，不能只写 DELETE FROM t。
参数差异和兼容性影响：
- PostgreSQL 示例：
DELETE FROM a USING b WHERE a.id = b.a_id AND b.a_id IS NULL❌ 错误；正确写法是DELETE FROM a WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id)，或用USING配合WHERE判定缺失：DELETE FROM a USING (SELECT DISTINCT a_id FROM b) AS b2 WHERE a.id = b2.a_id IS FALSE - SQL Server 允许
DELETE a FROM a LEFT JOIN b ON a.id = b.a_id WHERE b.a_id IS NULL，但要注意：如果 B 表没有索引在a_id上，性能会断崖式下降 - 所有数据库都建议在关联字段上建索引，尤其是子查询里的被驱动表字段（如 B 表的
a_id），否则NOT EXISTS可能退化成嵌套循环全表扫描
删之前不备份，等于给生产库埋雷
DELETE 没有后悔药。哪怕你确认逻辑 100% 正确，也得防索引失效、统计信息陈旧、或者某个隐藏的触发器悄悄改了语义。
容易踩的坑：
- 在从库上执行
DELETE—— 多数从库设为只读，但有些运维会临时关掉read_only，结果删完才发现 binlog 没同步过去，主从数据裂开 - 用 ORM 拼 SQL，比如 TypeORM 的
delete().where()底层可能生成带子查询的语句，但某些版本对NOT EXISTS支持不完整，生成的 SQL 语法错误 - 以为加了
LIMIT就安全，但在 MySQL 5.7 以前，DELETE ... LIMIT和ORDER BY组合可能不生效，删的不是你想删的那几条
真正麻烦的不是语法怎么写，而是删完之后发现业务报错——比如某个配置表被清掉了，但代码里没做空值判断，直接 NPE。这种问题不会在 DELETE 语句里暴露，得靠上下游依赖梳理和删前快照比对。
