NOT EXISTS比NOT IN更可靠，因其不依赖值比较而只判断行存在性，子查询含NULL时NOT IN恒为UNKNOWN致结果为空，NOT EXISTS则正常返回；关键在关联子查询中用WHERE绑定外键与主键，且两者字段均需索引。
直接结论：用 NOT EXISTS 查孤立外键，核心是把子查询写成“检查主表是否存在对应主键”，而不是“用 NOT IN 列表匹配”——后者遇到 NULL 会全返回空结果。
为什么 NOT EXISTS 比 NOT IN 更可靠？
孤立外键记录指子表中某条记录的外键值，在主表的主键列里找不到匹配项。常见错误是写成：
SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers);
只要 customers.id 里有一个 NULL，整个 NOT IN 表达式就恒为 UNKNOWN，结果集为空——这完全掩盖了真实问题。
NOT EXISTS 不受 NULL 影响，它只关心子查询是否返回行：
- 子查询返回至少一行 →
EXISTS为真 →NOT EXISTS为假 - 子查询无返回 →
EXISTS为假 →NOT EXISTS为真
标准写法：关联子查询必须用 WHERE 关联外键和主键
子查询不能独立执行，必须通过相关列（correlated column）把子表外键和主表主键绑在一起。漏掉这步，NOT EXISTS 就变成“查主表是否为空”。
正确示例（查所有没有对应客户的订单）：
SELECT o.* FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id );
-
SELECT 1是惯用写法，不查实际数据，只判断存在性 -
WHERE c.id = o.customer_id是关键：把子查询和外部orders的当前行绑定 - 别写成
WHERE c.id = 123这种固定值，那就失去相关性了
性能注意：外键字段和主键字段都要有索引
NOT EXISTS 底层通常走半连接（semi-join），但前提是数据库能快速定位匹配行。如果 customers.id 没索引，或 orders.customer_id 没索引，单次子查询可能要扫全表，整体变成 O(n×m) 复杂度。
- 确保主表主键（如
customers.id）已有主键索引（通常默认存在） - 手动为子表外键列建索引：
CREATE INDEX idx_orders_customer_id ON orders(customer_id); - PostgreSQL/MySQL 8.0+ 可用
EXPLAIN看子查询是否用了索引扫描（关键词：Index Scan或ref）
扩展场景：多字段外键或软删除主表
真实业务中主表可能有状态字段（如 status = 'active'），这时子查询的 WHERE 条件要同步加上：
SELECT o.*
FROM orders o
WHERE NOT EXISTS (
SELECT 1
FROM customers c
WHERE c.id = o.customer_id
AND c.status = 'active'
);
多字段外键（如 (region, shop_id)）也一样，子查询里用 AND 全部对齐：
WHERE c.region = o.region AND c.shop_id = o.shop_id
漏掉任一条件，就会把部分有效记录误判为孤立。
最容易被忽略的是子查询里的 WHERE 关联条件——它不是可选的语法装饰，而是语义正确性的前提。少一个等号，结果就全错。
