NOT EXISTS 比 NOT IN 更适合集合完全匹配，因其不受NULL干扰、逻辑可靠且性能稳定；NOT IN 遇 NULL 会因三值逻辑返回空结果，导致误判。
NOT EXISTS 为什么比 NOT IN 更适合集合完全匹配
直接说结论：当需要确认「A集合的每一条都存在于B集合中」这类全量包含关系时，NOT EXISTS 是更可靠的选择，尤其在B集合字段可能含 NULL 时。NOT IN 遇到 NULL 会整体返回空结果——这是最常踩的坑。
根本原因在于三值逻辑：value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而 value != NULL 永远是 UNKNOWN，整个表达式就变成 FALSE AND UNKNOWN → UNKNOWN，最终被当作不满足条件过滤掉。
-
NOT EXISTS只关心子查询是否返回行，不依赖字段值比较，天然规避NULL干扰 - 适用于主从表校验、权限全集比对、配置项完整性检查等场景
- 执行计划通常能走关联索引（如果外键或连接字段有索引），性能比
NOT IN更稳定
写法模板：用 NOT EXISTS 表达「A中所有记录都在B中」
核心思路是「找反例」：先假设A中某条记录不在B中，如果找不到这样的记录，就说明A被B完全包含。
典型结构：
SELECT a.*
FROM table_a a
WHERE NOT EXISTS (
SELECT 1
FROM table_b b
WHERE b.key_col = a.key_col
AND b.attr_col = a.attr_col
);注意点：
- 子查询里必须做**等值关联**（
b.key_col = a.key_col），否则NOT EXISTS失去意义 - 若要校验多字段组合（比如「用户拥有的全部角色」是否都在白名单中），
WHERE条件需覆盖所有维度，不能只比主键 - 子查询中
SELECT 1是惯例，写SELECT *或具体字段不影响逻辑，但语义上1最清晰 - 外层
SELECT返回的是「在B中找不到对应项的A记录」——所以想查「完全匹配的A」，实际要取反：即这个查询**返回空结果集**，才代表完全匹配
实战例子：检查用户权限是否全部落在系统预设角色内
假设有两张表：user_role（用户-角色映射）和 allowed_role（系统允许的角色白名单）。要验证用户ID=123的所有角色是否都在白名单中。
错误写法（用 NOT IN）：
SELECT * FROM user_role WHERE user_id = 123 AND role_code NOT IN (SELECT role_code FROM allowed_role);
如果 allowed_role.role_code 有 NULL，整条查询直接不返回任何行，哪怕用户有非法角色也看不出来。
正确写法（用 NOT EXISTS）：
SELECT ur.*
FROM user_role ur
WHERE ur.user_id = 123
AND NOT EXISTS (
SELECT 1
FROM allowed_role ar
WHERE ar.role_code = ur.role_code
);运行后如果返回 0 行，说明该用户所有角色都在白名单中；只要返回任意一行，就代表存在越权角色。
- 这个查询可直接用于应用层判断逻辑，无需额外处理空结果
- 如果要一次性检查多个用户，把外层
WHERE ur.user_id = 123换成ur.user_id IN (123, 456)即可 - 务必确保
allowed_role.role_code上有索引，否则子查询会变全表扫描
容易忽略的边界：空集合与全表扫描代价
当 table_b 是空表时，NOT EXISTS 子查询永远不返回行，因此外层 NOT EXISTS 恒为真——这意味着「如果白名单为空，所有用户都会被判为合法」。这往往不符合业务预期，需要前置校验。
另一个隐性成本：如果外层表很大且缺乏有效过滤条件，数据库可能对每行都执行一次子查询，即使加了索引，I/O 和 CPU 开销也不容小觑。
- 务必在外层加足够强的
WHERE条件（如限定单个用户、日期范围等），避免扫全表 - 在关键路径上使用前，用
EXPLAIN看执行计划，确认子查询走了索引而非DEPENDENT SUBQUERY的嵌套循环 - 如果业务允许近似判断，可考虑先用聚合（如
COUNT(*)对比总数）快速筛掉明显不匹配的情况，再用NOT EXISTS做精确校验
