not in遇null返回空集是sql三值逻辑标准行为，因id not in (a,b,null)等价于id!=a and id!=b and id!=null，其中id!=null恒为unknown，致整个条件为unknown而被where过滤；应改用带关联条件的not exists。
NOT IN 遇到子查询返回 NULL，整个 WHERE 条件会变成 UNKNOWN，被数据库直接丢弃——不是 bug，是 SQL 标准定义的三值逻辑行为。
NOT IN 的底层逻辑其实是 AND 链式比较
当你写 WHERE id NOT IN (SELECT user_id FROM logs)，数据库实际执行的是：id != value1 AND id != value2 AND id != NULL。
而 id != NULL 在 SQL 中永远返回 UNKNOWN（不是 TRUE 也不是 FALSE），整个 AND 表达式只要有一个 UNKNOWN，结果就是 UNKNOWN。WHERE 只保留 TRUE 行，UNKNOWN 和 FALSE 都被过滤掉——所以查不到任何数据。
- 哪怕子查询只返回一个
NULL，整条语句就“静默失效” - 子查询返回空集（0 行）时反而能查出全部数据，和含
NULL的行为完全相反，极易误判 - 这个行为在 MySQL、PostgreSQL、SQL Server、Oracle 中全部一致，不是某家数据库的缺陷
NOT EXISTS 为什么能绕过这个问题
NOT EXISTS 不做值比较，只判断子查询是否「返回至少一行」。NULL 值不影响行是否存在——只要 WHERE 条件能匹配上某行，就算有结果；没匹配上，就是空集。
所以它天然免疫 NULL 干扰，语义也更贴近“差集”本意。
- 必须写成相关子查询：子查询里要有
WHERE inner.id = outer.id这类关联条件 - 子查询里用
SELECT 1就够了，别写SELECT *或具体字段 - 外层表别名不能漏，否则可能触发全表扫描（比如写成
u.id = id而非u.id = o.id） - 原
NOT IN子查询里的其他条件（如status = 'failed'）必须平移进EXISTS的WHERE中，否则逻辑不等价
LEFT JOIN + IS NULL 是更直观的替代方案
如果你习惯显式连接，LEFT JOIN 配合 IS NULL 是语义最直白的写法：SELECT o.* FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL。
它把“不在另一张表中”翻译成“左连接后右表字段为 NULL”，没有隐含逻辑跳跃。
- 性能通常稳定，尤其当
ON字段有索引时 - 比
NOT EXISTS更容易加中间调试字段（比如查出u.name看为什么没连上） - 注意：如果右表有重复匹配行，
LEFT JOIN会产生笛卡尔膨胀，此时NOT EXISTS更安全
真正容易被忽略的点是：很多人改用 NOT EXISTS 后仍出错，不是因为语法写错，而是忘了把原子查询的过滤条件（比如时间范围、状态码）一并挪进子查询的 WHERE 里——结果查出来的不是“未关联的记录”，而是“未按条件关联的记录”，语义已偏移。
