DELETE + LEFT JOIN 是删除孤儿记录的正确方法，如 DELETE o FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL；必须建索引、先 SELECT 验证、注意删的是子表而非主表。
DELETE + LEFT JOIN 找出并删掉“孤儿记录”
想删掉子表里那些找不到主表对应记录的脏数据，比如 orders 表中 user_id 指向已不存在用户的订单，就得用 LEFT JOIN 配合 WHERE ... IS NULL。INNER JOIN 会漏掉这些行，因为它只保留两边都匹配的记录。
正确写法是把主表（如 users）放右边，子表（如 orders）放左边，再筛出右表为 NULL 的行：
DELETE o FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL;
常见错误：把 users 放在 FROM 后面，结果删的是用户而不是订单；或者 WHERE 条件写成 o.user_id IS NULL，这只会删掉字段本身为空的记录，不是“关联断裂”的孤儿数据。
- 必须给
o.user_id建索引，否则 JOIN 时全表扫描，100 万行订单 × 100 万行用户 = 百亿级比对 - 执行前先用
SELECT o.*替换DELETE o，确认要删的确实是预期数据 - MySQL 8.0+ 支持直接
DELETE FROM ... USING语法，语义更清晰，但 LEFT JOIN 写法兼容性更好
DELETE + INNER JOIN 清理“双向有效关联”数据
当你要删掉主表和子表中**同时满足某条件**的记录，比如“所有状态为 'draft' 的订单及其明细”，就得用 INNER JOIN。它不会误删孤立记录，也不会漏删没明细的订单——因为目标本来就是“有明细且为草稿”的组合。
典型写法：
DELETE o, oi FROM orders o INNER JOIN order_items oi ON o.id = oi.order_id WHERE o.status = 'draft';
注意点：
-
DELETE o, oi表示同时删两个表；如果只想删子表，就只写DELETE oi - JOIN 条件字段（
oi.order_id）必须单独建索引，仅靠orders.id主键索引不够 - WHERE 中的过滤条件（如
o.status = 'draft'）建议也放进 ON 子句，让数据库尽早下推，减少中间连接量 - 若某订单无明细，它根本不会出现在 JOIN 结果里，自然不会被删——这是预期行为，不是 bug
外键约束下删主表前必须手动清理子表
直接 DELETE FROM users WHERE id = 123 报错 ERROR: update or delete on table "users" violates foreign key constraint？说明至少一张子表（如 profiles、addresses）通过外键引用了它，且没设 ON DELETE CASCADE。
此时不能依赖单条语句，必须按依赖顺序手动删：
- 先查清所有依赖：PostgreSQL 用
SELECT conname, confdeltype FROM pg_constraint WHERE confrelid = 'users'::regclass AND contype = 'f'；MySQL 查INFORMATION_SCHEMA.KEY_COLUMN_USAGE - 按“子表 → 主表”顺序写 DELETE，例如：
DELETE FROM user_sessions WHERE user_id = 123→DELETE FROM profiles WHERE user_id = 123→DELETE FROM users WHERE id = 123 - 整套操作必须包在
BEGIN/COMMIT事务里，任一环节失败可ROLLBACK回退 - 别跳过任何一张子表——漏删一张，下次删同个用户还会报错
删完不等于空间释放，大表必须后续处理
执行完 DELETE，SELECT COUNT(*) 行数少了，但磁盘空间纹丝不动，这是常态。InnoDB 和 PostgreSQL 都只做标记删除，旧数据页仍占位置，甚至拖慢后续查询（MVCC 版本链变长、buffer pool 命中率下降）。
必须补操作：
- MySQL：小表跑
OPTIMIZE TABLE orders；中大表用ALTER TABLE orders ENGINE=InnoDB（语义更明确，支持在线 DDL） - PostgreSQL：日常用
VACUUM orders；真要缩文件大小才用VACUUM FULL orders（锁表、需双倍磁盘空间） - 千万别在高峰期执行
VACUUM FULL或OPTIMIZE TABLE，监控pg_stat_progress_vacuum或innodb_buffer_pool_wait_free防卡死 - TRUNCATE 不适用——它清空整表，而你只是删部分无效数据
最易被忽略的是：删完不处理空间，过几个月发现磁盘爆满，查日志才发现是半年前那批 DELETE 没收尾。
