安全识别“孤儿记录”应优先用not exists或left join...is null；not in因null值会导致结果为空，易引发误删；not exists对null免疫、性能更优，且需确保关联字段有索引并先用select验证。
子查询怎么写才能安全识别“孤儿记录”
直接用 SELECT 配合 NOT EXISTS 或 LEFT JOIN ... IS NULL 是最稳妥的方式，避免误删。用 NOT IN 容易因子查询返回 NULL 导致整条语句不返回任何结果——这是线上误删的高发原因。
-
NOT EXISTS性能通常更好，且对NULL值天然免疫，推荐作为默认选择 -
LEFT JOIN方式更直观，适合调试时验证哪些记录会被匹配上 - 务必在子查询中显式过滤掉被关联表的
NULL值（比如WHERE parent_id IS NOT NULL），否则外键字段本身为NULL的记录也会被当成“孤儿”误删
DELETE 语句里嵌套子查询的写法限制
MySQL 不允许在 DELETE 中直接使用目标表名做子查询（报错 You can't specify target table for update in FROM clause）。PostgreSQL 和 SQL Server 没这限制，但 MySQL 用户必须绕开。
- 用临时表包装子查询结果：
DELETE FROM child_table WHERE id NOT IN (SELECT id FROM (SELECT id FROM parent_table) AS tmp) - 改用
JOIN语法（MySQL 推荐）：DELETE c FROM child_table c LEFT JOIN parent_table p ON c.parent_id = p.id WHERE p.id IS NULL - SQLite 不支持多表
DELETE，只能用NOT EXISTS子查询，且需确保外键列有索引，否则全表扫描极慢
外键约束开启状态下能不能直接删
如果数据库已定义了 ON DELETE CASCADE，那根本不需要手动清理——级联会自动处理。但现实中大量老系统外键是失效或未启用的，这时得靠子查询补救。
- 先查外键状态：
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS rc ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME WHERE kcu.TABLE_NAME = 'child_table' - 若
DELETE_RULE是NO ACTION或RESTRICT，说明不会自动清理，必须人工介入 - 执行前务必加事务并限流：
BEGIN; DELETE ... LIMIT 1000; COMMIT;，防止锁表太久影响业务
为什么加了索引还是慢
子查询性能瓶颈常不在外键字段本身，而在子查询结果集是否可复用、连接方式是否走索引、以及统计信息是否过期。
- 检查执行计划：
EXPLAIN SELECT * FROM child_table WHERE NOT EXISTS (SELECT 1 FROM parent_table WHERE parent_table.id = child_table.parent_id)，确认parent_table.id走了主键索引 - 如果
child_table.parent_id上没索引，NOT EXISTS会触发对每行都做一次全表扫描——这是最常被忽略的性能坑 - PostgreSQL 用户注意：子查询里用
SELECT 1比SELECT *更轻量，优化器更容易命中索引-only scan
实际执行前，永远先跑一遍 SELECT 版本看数据量，再决定要不要分批、加索引或临时禁用触发器。外键逻辑分散在应用层时，数据库层面的“孤儿”判定反而最不可靠——这时候得回代码里确认真实关联逻辑。
