最稳妥的安全差集删除方式是使用 DELETE + NOT EXISTS，它能正确处理 NULL 值且兼容主流数据库；需先用 SELECT 验证逻辑，注意列名明确关联、避免 NOT IN 因 NULL 导致失效，并警惕外键约束引发的静默失败。
用 DELETE + NOT EXISTS 实现安全差集删除
直接用 DELETE 删除「A 表有但 B 表没有」的数据，最稳妥的方式是搭配 NOT EXISTS 子查询。它比 NOT IN 更可靠，能正确处理 NULL 值，且多数数据库（MySQL 5.7+、PostgreSQL、SQL Server）都支持。
假设要从 orders 表中删掉那些在 processed_logs 表里找不到对应 order_id 的记录：
DELETE FROM orders WHERE NOT EXISTS ( SELECT 1 FROM processed_logs WHERE processed_logs.order_id = orders.order_id );
-
SELECT 1是惯用写法，比SELECT *更轻量，语义也更清晰 - 子查询中的列名必须明确关联，不能只写
order_id—— 否则可能误关联或报错「ambiguous column」 - 务必先用
SELECT验证逻辑：SELECT * FROM orders WHERE NOT EXISTS (...)，确认要删的行数和内容无误再执行DELETE
MySQL 中用 LEFT JOIN + IS NULL 的替代写法
MySQL 旧版本（如 5.6）对 NOT EXISTS 的优化不够好，有时用 LEFT JOIN 更快；但要注意语法限制：MySQL 不允许在 DELETE 中直接给主表起别名后用 JOIN，必须写成多表 DELETE 形式。
DELETE o FROM orders AS o LEFT JOIN processed_logs AS p ON o.order_id = p.order_id WHERE p.order_id IS NULL;
- 必须显式写出
DELETE o FROM orders AS o，不能省略AS o或别名o -
WHERE p.order_id IS NULL是关键判断条件，不能写成p.id IS NULL（列名不匹配会静默失败） - 该写法在
processed_logs.order_id无索引时性能明显下降，建议确保该字段建了索引
避免踩坑：NOT IN 导致全表误删的典型场景
NOT IN 看似简洁，但只要子查询结果里含任意一个 NULL，整个条件就会恒为 UNKNOWN，导致 DELETE 不生效 —— 表面看没报错，实际一行都没删；更危险的是，某些 ORM 拼接 SQL 时未过滤 NULL，可能引发线上事故。
- 错误示例：
DELETE FROM orders WHERE order_id NOT IN (SELECT order_id FROM processed_logs) - 如果
processed_logs.order_id里有一条是NULL，整条NOT IN判断失效，WHERE条件永远不成立 - 修复方式只有两个：加
WHERE order_id IS NOT NULL到子查询中，或直接换用NOT EXISTS - PostgreSQL 和 SQL Server 对
NOT IN的行为一致，不是 MySQL 特有，别心存侥幸
外键约束下删除失败的静默表现
如果 orders 被其他表（如 order_items）通过外键引用，默认级联行为是 RESTRICT，此时 DELETE 会直接报错，比如 MySQL 报 Cannot delete or update a parent row；但有些应用层代码捕获异常后仅打日志不抛出，看起来就像“删不动”。
- 先查外键关系：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'orders'; - 临时禁用外键检查（仅限开发/测试）：
SET FOREIGN_KEY_CHECKS = 0;，删完记得设回1 - 生产环境应优先考虑业务逻辑：是否真要硬删？还是改用软删（加
is_deleted字段）更安全
差集删除真正难的不是语法，而是确认「哪些数据确实该被删」—— 比如时间范围是否跨天、状态字段是否参与判断、归档表是否已同步。别跳过验证步骤。
