NOT EXISTS 比 NOT IN 更安全，因为当子查询含 NULL 时 NOT IN 返回空结果集，而 NOT EXISTS 对 NULL 不敏感、结果稳定；它适用于存在性判断，且 SELECT 1 可提升优化器效率。
NOT EXISTS 为什么比 NOT IN 更安全
当B表的关联字段（比如 org_id）包含 NULL 值时，NOT IN 会整个返回空结果集——这是最容易被忽略的语义陷阱。而 NOT EXISTS 只关心子查询是否返回行，完全绕过 NULL 判断逻辑，结果稳定可靠。
常见错误现象：SELECT * FROM people WHERE org_id NOT IN (SELECT org_id FROM org) 查不到任何数据，但实际确实存在组织ID缺失的记录。
-
NOT IN在子查询含NULL时等价于WHERE FALSE OR UNKNOWN，整条条件失效 -
NOT EXISTS对NULL不敏感，只要子查询没匹配上就返回主表行 - MySQL/PostgreSQL/SQL Server 全部支持，语法一致，迁移成本低
查“每个用户缺哪些必选文档类型”的标准写法
这不是简单两表对比，而是需要先构造“用户 × 必选类型”的全量组合，再排除已存在的组合。核心是用 CROSS JOIN + NOT EXISTS。
假设必选类型固定为 'type1'、'type2'、'type3'，用户表叫 users，已有记录存于 user_docs（含 user_id, doc_type）：
SELECT u.user_id, req.type AS missing_type
FROM users u
CROSS JOIN (VALUES ('type1'), ('type2'), ('type3')) AS req(type)
WHERE NOT EXISTS (
SELECT 1 FROM user_docs d
WHERE d.user_id = u.user_id AND d.doc_type = req.type
);注意点：
- 不要用
NOT IN (SELECT doc_type FROM user_docs WHERE user_id = u.user_id)—— 子查询可能为空，导致整行被跳过 -
VALUES行构造器在 PostgreSQL / SQL Server 支持良好；MySQL 8.0+ 也支持，5.7 请改用UNION ALL模拟 - 如果必选类型来自另一张配置表，直接
CROSS JOIN config_types即可
大表场景下性能关键：索引和关联字段类型必须一致
20万行以上数据时，NOT EXISTS 的性能几乎完全取决于子查询能否走索引。一旦发生全表扫描，查询可能从毫秒级变成分钟级。
典型翻车现场：
- 主表
user_docs.user_id是BIGINT，子查询里users.id是INT→ 类型隐式转换，索引失效 - 关联字段没索引，或索引只建在单列，但子查询条件是
WHERE a=x AND b=y→ 需要联合索引 - 子查询里用了函数，比如
WHERE UPPER(b.name) = UPPER(a.name)→ 索引无法命中
实操建议：对子查询中 WHERE 条件涉及的所有字段，建立覆盖索引。例如子查询是 SELECT 1 FROM org WHERE id = u.org_id，就在 org(id) 上建索引。
LEFT JOIN 替代方案？只在需要 B 表字段时才用
如果只是判断“是否存在”，NOT EXISTS 语义清晰、执行计划通常更优；但如果后续还要取 B 表的其他字段（比如缺失原因、创建时间），LEFT JOIN 才是合理选择。
错误混用：
- 写
LEFT JOIN ... WHERE b.id IS NULL却又在SELECT里取了b.created_at→ 实际永远为NULL，徒增逻辑混乱 - 用
LEFT JOIN查“用户缺哪些类型”时，忘记加GROUP BY或去重，导致结果膨胀
记住：判断存在性用 NOT EXISTS；需要右表数据才用 LEFT JOIN。两者不是风格偏好，而是语义分工。
最易被忽略的点：子查询里的 SELECT 1 不是占位符习惯，而是明确告诉优化器“我只关心是否存在”，避免引擎去读取无用列。换成 SELECT * 在某些旧版 MySQL 中可能触发额外字段解析开销。
