DELETE不支持标准JOIN，应使用NOT EXISTS子查询删除孤儿记录，如DELETE FROM comments WHERE NOT EXISTS (SELECT 1 FROM posts WHERE posts.id = comments.post_id)，语义清晰、索引友好且规避NULL陷阱。
DELETE 语句不支持直接 JOIN，得用子查询或 EXISTS
SQL 标准里 DELETE 本身不接受 JOIN 语法（MySQL 5.7+ 虽支持 DELETE ... FROM t1 JOIN t2，但可移植性差，且易误删）。真正安全、通用的做法是把「被关联表中不存在对应记录」这个逻辑，转成子查询或 EXISTS/NOT EXISTS。
比如要删掉所有在 orders 表中没有对应 user_id 的 users 记录（即用户表里的孤儿用户），不能写：
DELETE FROM users JOIN orders ON users.id = orders.user_id WHERE orders.user_id IS NULL;
而应该写：
- 用
NOT EXISTS（推荐）：语义清晰、索引友好、避免 NULL 陷阱 - 用
NOT IN要小心：如果子查询结果含NULL，整条语句返回空集，一条都删不掉 - 先
SELECT验证再删：永远先跑一遍SELECT id FROM users WHERE NOT EXISTS (...)
用 NOT EXISTS 删除外键缺失的孤儿记录
NOT EXISTS 是处理孤儿记录最稳的方式，它不依赖值是否为 NULL，只关心子查询是否返回行。
假设你有 comments 表（含 post_id）和 posts 表（主键 id），想删掉所有指向已删除文章的评论：
DELETE FROM comments WHERE NOT EXISTS ( SELECT 1 FROM posts WHERE posts.id = comments.post_id );
关键点：
- 子查询里必须关联外键字段（
posts.id = comments.post_id），否则变成全量删 -
SELECT 1是惯用写法，比SELECT *略快，数据库不真取数据 - 确保
posts.id和comments.post_id类型一致，否则可能隐式转换导致索引失效 - 如果
comments.post_id允许为NULL，这条语句也会删掉它们——这是预期行为（NULL 本身就是孤儿）
用 LEFT JOIN + IS NULL 模拟（仅限 MySQL/PostgreSQL）
某些数据库（如 MySQL、PostgreSQL）允许在 DELETE 中用 JOIN，但必须明确指定删哪张表，并用 LEFT JOIN 找出右表为空的行。
同样删 comments 中的孤儿记录：
DELETE c FROM comments c LEFT JOIN posts p ON c.post_id = p.id WHERE p.id IS NULL;
注意：
- MySQL 必须写
DELETE c FROM comments c，不能省略别名c，否则语法报错 - PostgreSQL 不支持这种写法，得用
USING：DELETE FROM comments c USING posts p WHERE c.post_id = p.id AND p.id IS NULL—— 但这样逻辑反了，实际要用NOT EXISTS更稳妥 - 这种写法在大表上容易锁住
posts表，而NOT EXISTS只查索引列，压力更小
外键没设 ON DELETE CASCADE？那得手动维护一致性
如果你的表之间本该有外键约束，但没加 ON DELETE CASCADE 或 ON DELETE SET NULL，那每次删主表前就得手动清理子表。这种场景下，孤儿记录不是意外，而是设计遗留问题。
建议动作：
- 先用
SHOW CREATE TABLE comments查外键定义，确认是否真没设级联 - 补外键时注意：如果已有孤儿数据，
ADD CONSTRAINT会失败，得先清理再加 - 临时脚本里别只删一次——业务高峰期可能持续产生新孤儿，考虑加定时任务或触发器（但触发器有性能代价）
- 最常被忽略的是：
NOT EXISTS子查询里如果涉及多层关联或函数，执行计划可能走全表扫描，务必EXPLAIN一下
