关键在删前确认孤立性并避开NULL陷阱与全表扫描；应优先用NOT EXISTS替代NOT IN，因其不受NULL影响、语义精准且优化器更易生成高效执行计划，再通过SELECT验证后分批DELETE。
直接删孤立数据不难，难的是删完不破坏业务逻辑、不触发外键异常、不拖垮线上查询——关键不在“怎么删”，而在“删之前怎么确认它真是孤立的”和“删的时候怎么避开 NULL 陷阱与全表扫描”。
用 NOT EXISTS 而不是 NOT IN 判断孤立记录
很多人在写删除语句时习惯用 NOT IN，比如：
DELETE FROM orders WHERE user_id NOT IN (SELECT id FROM users);
这在 users.id 存在 NULL 值时会整个失效（SQL 标准规定：expr NOT IN (NULL, ...) 永远返回 UNKNOWN，即不匹配任何行），结果就是一条没删掉，还误以为安全。
-
NOT EXISTS不受NULL影响，语义更贴近“对每条 orders 记录，检查是否存在对应的 users.id” - 数据库优化器通常能为
NOT EXISTS生成更优的执行计划（如半连接、索引嵌套循环） - 在 PostgreSQL 和 MySQL 8.0+ 中，
NOT EXISTS的性能普遍优于NOT IN，尤其当子查询结果集较大时
先 SELECT 验证，再分批 DELETE
孤立数据常集中在历史归档表或软删除残留区，一次性全删可能锁表数分钟，甚至触发主从延迟告警。必须把“查”和“删”拆开做：
- 先跑一次识别语句，确认数量和样本：
SELECT id, user_id, created_at FROM orders WHERE NOT EXISTS (SELECT 1 FROM users WHERE users.id = orders.user_id) LIMIT 20;
- 人工抽样核对几条，确认它们确实无业务关联（比如不是审计日志、不是被软删除用户的历史订单）
- 真正删时加
LIMIT+ 循环（MySQL 支持，PostgreSQL 需用WITH ... DELETE或应用层控制）：DELETE FROM orders WHERE NOT EXISTS (SELECT 1 FROM users WHERE users.id = orders.user_id) LIMIT 1000;
- 每次删完暂停 1–2 秒，避免 IO 打满；用
ROW_COUNT()（MySQL）或GET DIAGNOSTICS（PG）判断是否还有剩余
外键约束下 DELETE 的实际行为必须明确
即使你用 NOT EXISTS 安全删了子表，也不能假设主表就“安全”——因为外键定义决定了级联动作是否生效：
- 如果外键是
ON DELETE RESTRICT（默认），你删主表某条users.id时，只要orders还有引用，就会报错：ERROR: update or delete on table "users" violates foreign key constraint - 如果是
ON DELETE CASCADE，删users会自动连带删orders，但你无法控制删哪些orders，也看不到中间过程 - 真正维护引用完整性，不是靠“删得快”，而是靠“删得可控”：优先清理子表孤立记录，再考虑主表归档或软删除，避免依赖级联机制
最易被忽略的一点：孤立数据未必该删。有些系统把“用户注销后保留订单”作为合规要求，此时 user_id 指向已注销用户，不是 bug，是 feature。动手前翻一翻业务文档或找产品确认，比调十条 SQL 更省时间。
