not exists比left join + is null更安全，因其仅判断子查询是否存在匹配行，不依赖连接字段是否为null或重复，而left join在右表含null或重复匹配时易误判“不存在”。
NOT EXISTS 为什么比 LEFT JOIN + IS NULL 更安全
因为 NOT EXISTS 只关心子查询是否返回任意一行，不依赖外键字段是否为 NULL，也不受连接字段重复或 NULL 值干扰。而 LEFT JOIN 在右表有重复匹配、或连接字段本身含 NULL 时，IS NULL 判定容易误判——比如左表某行本该被排除，却因右表多条 NULL 匹配而意外保留。
标准差集写法：查 A 表有但 B 表没有的记录
假设要查 orders 表中客户 ID 不在 customers 表里的订单（即“无效订单”），正确结构是：
SELECT o.* FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM customers c WHERE c.customer_id = o.customer_id );
-
SELECT 1是惯用写法，子查询只判断存在性，不取实际数据，性能更轻量 - 子查询中的关联条件
c.customer_id = o.customer_id必须显式写出，不能省略或错写成=反向或常量 - 子查询里不能加
ORDER BY或LIMIT，否则多数数据库（如 MySQL 8.0+、PostgreSQL）会报错
容易踩的坑：子查询漏关联或写错作用域
常见错误是把子查询写成独立查询，导致变成“全表检查”，结果恒为假或恒为真：
- ❌ 错误：
WHERE NOT EXISTS (SELECT 1 FROM customers WHERE customer_id = 123)—— 这不是关联子查询，而是固定值检查 - ❌ 错误：
WHERE NOT EXISTS (SELECT 1 FROM customers c WHERE c.id = o.id)—— 但主查询别名是o，而orders表根本没有id字段，应为customer_id - ⚠️ 注意：子查询中引用的外部列（如
o.customer_id）必须在主查询的FROM范围内可见；若主查询用了嵌套，外层别名在子查询里不可见
性能关键：相关列必须有索引
NOT EXISTS 的效率高度依赖子查询中 WHERE 条件字段的索引。例如上面例子中，customers(customer_id) 必须有索引，否则每次都要全表扫描 customers。
- 如果子查询条件含多个字段（如
WHERE c.status = 'active' AND c.customer_id = o.customer_id），建议建联合索引：INDEX(status, customer_id) - MySQL 5.7+ 和 PostgreSQL 会尝试将
NOT EXISTS优化为半连接（semi-join），但前提是子查询干净、无歧义；一旦子查询里出现OR、函数包装（如UPPER(c.name)）或GROUP BY，优化器大概率退化为嵌套循环
实际用的时候，最常被忽略的是子查询里那个看似微小的关联条件——写错字段名、拼错别名、或者忘了加前缀，都会让整个查询逻辑失效，且不容易一眼看出来。
