很多人比较 NOT IN 和 NOT EXISTS 时，先想到的是执行性能，但线上最容易出事的往往不是快慢，而是结果是否可靠。本文从 NULL 语义、索引执行、写法约束和并发场景四个角度拆开讲，说明为什么大多数业务 SQL 里应优先选 NOT EXISTS，以及 NOT IN 只有在什么前提下才算勉强可用。
`NOT IN` 遇到 `NULL`，问题是逻辑错误不是性能问题
NOT IN 最致命的坑，是子查询结果里只要出现任意一个 NULL，整个判断就可能失效。此时条件不会得到你直觉中的“排除部分行”，而是会变成 UNKNOWN，最终被 WHERE 过滤掉。
例如下面这条语句：
SELECT * FROM t1 WHERE c2 NOT IN (SELECT c2 FROM t2)
如果 t2.c2 中有一条记录是 NULL，那么即使 t1 里有 1000 行根本匹配不上，也可能一条都查不出来。
这符合 SQL 的三值逻辑：条件结果不只有 TRUE、FALSE，还可能是 UNKNOWN。但从业务角度看，这种行为非常危险，因为多数人写这类语句时，期待的是“排除命中的记录”，而不是“整批结果被吞掉”。
为什么 `NOT EXISTS` 不会踩这个坑
NOT EXISTS 判断的是“是否存在匹配行”，而不是“某个值是否不属于一个集合”。它只关心关联条件能不能命中，因此 NULL 不会像 NOT IN 一样把整个条件拖入 UNKNOWN。
更重要的是，即便表结构上定义了 NOT NULL，也不能把这件事当成绝对保险。ETL 异常、历史脏数据、空字符串转义失败，都可能让你在生产库里碰到意料之外的 NULL。
执行计划上，`NOT EXISTS` 更容易利用索引
除了语义更稳，NOT EXISTS 在很多数据库里也更符合优化器的处理习惯。NOT IN 常见的执行方式，是先跑子查询、物化结果集，再拿外层记录逐行比对；而 NOT EXISTS 更容易被优化器改写成 Anti Join，再配合内表索引完成快速定位。
典型场景如下：
- 如果
task_msg_contract.contract_id上有索引，NOT EXISTS (SELECT 1 FROM task_msg_contract WHERE t.id = contract_id)往往可以直接走索引查找。 - 同样的业务逻辑，
NOT IN (SELECT contract_id FROM task_msg_contract)则更容易触发t表和task_msg_contract表的双重全表扫描。 - 当子查询表很大、主表很小，例如只想判断一条记录是否“孤立”时，
NOT EXISTS的优势通常会更明显。
这里该关注的不是“绝对更快”
需要注意，具体执行计划仍取决于数据库类型、版本、统计信息和优化器实现，不能机械地说所有场景下 NOT EXISTS 一定更快。但从通用经验看，它更容易写出对索引友好的反关联查询，这比单纯盯着语法表面更重要。
`NOT EXISTS` 语义更直接，也更不容易写错
NOT IN 的写法本质上是“值集合对比”，看起来简短，但也因此隐藏了不少前提：字段类型要一致，比较字段要明确，子查询范围不能放大，还要保证没有额外的歧义。
常见误写包括：
WHERE id NOT IN (SELECT user_id FROM logs)：如果logs.user_id是VARCHAR，而id是INT，可能触发隐式转换问题，结果不准或性能变差。WHERE id NOT IN (SELECT id FROM other_table WHERE status = 'active')：一旦子查询条件写漏、范围过大，排除逻辑就会偏离原意。
相比之下，NOT EXISTS 通常要求你显式写出关联条件，例如：
WHERE NOT EXISTS (
SELECT 1
FROM inner_table
WHERE outer.id = inner.id
)
这种写法会把“外层记录”和“内层匹配条件”直接绑定在一起，阅读成本更低，也更不容易漏掉关键条件。
高并发场景下，`NOT IN` 更容易出现条件漂移
在并发环境中，风险还不止是 NULL 或慢查询。NOT IN 常见的理解方式，是先拿到子查询结果，再由主查询做排除。如果这两个阶段之间数据发生变化，就可能出现“判断依据已经过时”的问题。
例如删除未付款订单：
DELETE FROM orders WHERE order_id NOT IN (SELECT order_id FROM payments)
可能出现这样的时序：
- 子查询执行时，某笔订单刚完成支付，但事务还没提交，因此子查询没看到它。
- 等主查询真正执行删除时，这笔支付已经提交，数据库里实际上已经存在对应付款记录。
- 但由于
order_id不在先前拿到的子查询结果中，这笔订单仍可能被误删。
`NOT EXISTS` 为什么更适合这类判断
NOT EXISTS 的判断方式更接近“针对当前外层行，实时确认是否存在匹配记录”。只要事务隔离级别合理，例如 READ COMMITTED，它更容易反映出最新的一致状态，降低条件漂移带来的误判风险。
结论：默认优先 `NOT EXISTS`，`NOT IN` 只在前提极强时使用
这类选择真正该优先考虑的，不是“谁在某次压测里快了几毫秒”，而是“谁更不容易在边界条件下把结果做错”。从这个角度看，NOT EXISTS 更适合作为默认写法，原因很明确：
- 对
NULL更安全，不容易因为三值逻辑导致结果集整体失效； - 更容易利用索引和优化器的反关联执行能力；
- 关联条件写得更显式，代码可读性和可维护性更高；
- 在并发更新场景下，更不容易出现误删、误判。
只有当你能够同时确认这几个前提时，NOT IN 才勉强算是可接受的选择：子查询字段绝对不存在 NULL、数据量极小、字段类型完全一致，而且这条 SQL 的业务风险很低。除此之外，优先写成 NOT EXISTS，通常是更稳妥的工程决策。
