not exists比left join is null更可靠，因其语义明确、不依赖连接字段null处理，避免一对多重复匹配或null值导致的误判，且子查询必须关联外层表才能正确表达“是否存在匹配”。
NOT EXISTS 为什么比 LEFT JOIN IS NULL 更可靠
当你要找“在 A 表里存在、但在 B 表里没有对应记录”的数据时，NOT EXISTS 是语义最直接、行为最确定的方式。它不依赖连接键是否为 NULL，也不受 LEFT JOIN 中重复匹配或空值传播的影响。
常见错误现象：LEFT JOIN ... WHERE b.id IS NULL 在 B 表有多个匹配行（比如一对多）时可能漏掉本该被排除的 A 行；或者 B 表连接字段本身允许 NULL，导致 IS NULL 判定失真。
-
NOT EXISTS对每一行 A 独立执行子查询，只要子查询返回空集就保留该行，逻辑清晰无歧义 - 子查询中必须关联外层表（用
WHERE b.a_id = a.id这类条件），否则变成恒真/恒假，结果全错 - 子查询里写
SELECT 1或SELECT *都可以，优化器通常不关心 SELECT 列，但别写SELECT COUNT(*)—— 它会强制全扫描
标准写法：带关联条件的 NOT EXISTS 子查询
假设你有两个表：orders（订单）和 shipments（发货单），想查“已下单但尚未发货”的订单：
SELECT o.order_id, o.customer_id FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM shipments s WHERE s.order_id = o.order_id );
关键点：
- 子查询里的
s.order_id = o.order_id是**必须的关联条件**，漏掉就会变成“只要 shipments 表非空，所有 orders 都被过滤掉” - 子查询中不要加额外过滤（如
AND s.status != 'cancelled'）除非你明确要排除特定状态——否则它会改变“是否存在任意匹配”的原始语义 - 如果
shipments.order_id有索引，这个查询通常能走ANTI JOIN优化，性能接近哈希反连接
容易踩的坑：NULL 值和空子查询陷阱
当关联字段可能为 NULL 时，NOT EXISTS 依然安全，但很多人误以为它和 NOT IN 一样会被 NULL 拖垮——其实不会。
对比：WHERE order_id NOT IN (SELECT order_id FROM shipments) 在 shipments.order_id 含 NULL 时直接返回空结果集，而 NOT EXISTS 不受影响。
- 子查询里如果写了
WHERE ... AND s.order_id IS NOT NULL，反而可能人为排除有效匹配，没必要 - 子查询若写成
SELECT 1 FROM shipments WHERE order_id = o.order_id LIMIT 1，某些旧版 MySQL 会拒绝（不支持 LIMIT 在子查询中），应避免 - PostgreSQL 和 SQL Server 支持在子查询里引用多层外层表，但 MySQL 8.0 之前只支持一层，嵌套深了要改写
替代方案对比：什么时候不该用 NOT EXISTS
如果你实际需要的是“A 表有、B 表没有，且还要带 B 表的某些默认值”，那 NOT EXISTS 就不够用了——它只返回 A 表字段。这时得切回 LEFT JOIN，再用 COALESCE 补默认值。
- 要统计缺失比例？用
COUNT(*) FILTER (WHERE NOT EXISTS (...))（PostgreSQL）或条件聚合，别在外部再套一层 - 要查“缺失且满足某时间范围”的数据？把时间条件放在子查询里（
WHERE s.order_id = o.order_id AND s.created_at > '2024-01-01'），而不是外层加AND，否则逻辑错误 - Oracle 用户注意：
NOT EXISTS在某些版本对空子查询的处理略有差异，建议始终显式写SELECT 1而非SELECT *
NOT EXISTS，而是想清楚“缺失”的定义是否包含状态、时间、租户隔离等隐含维度——这些都得揉进子查询的 WHERE 条件里，少一个就查偏了。
