NOT EXISTS 比 LEFT JOIN + IS NULL 更安全，因其不依赖连接字段的 NULL 处理逻辑，避免因右表存在 NULL 导致误判；必须用相关子查询，且需为关联字段建立索引以保障性能。
NOT EXISTS 为什么比 LEFT JOIN + IS NULL 更安全
因为 NOT EXISTS 只关心子查询是否返回任意一行，不依赖连接字段的 NULL 处理逻辑。当右表存在 NULL 值时，LEFT JOIN ... WHERE right.id IS NULL 可能漏掉本该排除的行——这是初学者最常踩的坑。
实际场景中，比如「查所有没下过单的用户」，若订单表 orders.user_id 允许为 NULL，用 LEFT JOIN 就会把部分已下单但 user_id 为空的记录误判为“未下单”。
-
NOT EXISTS子查询里写的是相关子查询（带外部引用），语义清晰：对每行左表数据，检查右表是否存在匹配项 - 数据库优化器通常能高效处理
NOT EXISTS，尤其在右表有合适索引时（如WHERE user_id = outer.user_id） - 不推荐用
NOT IN (SELECT ...)：只要子查询结果含一个NULL，整个条件恒为UNKNOWN，结果集直接变空
标准写法：用相关子查询构造差集
假设要查 users 表中「从未出现在 orders 表中的用户」：
SELECT u.* FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
关键点：
- 子查询必须是相关子查询，即内部必须引用外部表字段（这里是
o.user_id = u.id） -
SELECT 1是惯用写法，只判断是否存在，不取实际数据；用SELECT *也行，但语义不清 - 子查询里不能加
GROUP BY或聚合函数，否则会破坏相关性，导致逻辑错误 - 如果需要多条件匹配（如按用户+时间范围排除），在子查询
WHERE中叠加即可：o.user_id = u.id AND o.created_at > '2024-01-01'
当右表有复合主键或需多字段匹配时怎么写
例如查「没有在 2024 年下过单的用户」，但订单表用 (user_id, order_year) 联合标识年度订单：
SELECT u.*
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
AND o.order_year = 2024
);注意：
- 多个匹配条件全部写在子查询的
WHERE中，用AND连接 - 不能写成
WHERE (o.user_id, o.order_year) = (u.id, 2024)—— MySQL 8.0.19+ 才支持行构造器比较，且多数旧版本和 PostgreSQL 不兼容 - 如果右表字段可能为
NULL（如order_year允许为空），需额外加IS NOT NULL判断，否则=比较会失效
性能陷阱：缺少索引会让 NOT EXISTS 变慢十倍
NOT EXISTS 的性能高度依赖子查询中用于关联的字段是否有索引。没有索引时，对左表每行都要全表扫描右表。
- 必须确保子查询
WHERE条件里的字段（如o.user_id）在右表上有索引 - 如果是复合条件（如
user_id = ? AND status = 'paid'），考虑建联合索引：CREATE INDEX idx_orders_user_status ON orders(user_id, status); - 执行前用
EXPLAIN看子查询是否走了索引：关注type是否为ref或range，而非ALL - 某些场景下，
NOT EXISTS和NOT IN的执行计划看似一样，但语义风险完全不同——别因执行快就选错语法
复杂点在于：子查询的写法必须严格对应业务语义，而不仅仅是“让 SQL 跑起来”。哪怕只漏一个 AND status != 'cancelled'，差集结果就错了，而且很难被测试覆盖到。
