NOT IN遇NULL返回空结果是SQL三值逻辑标准行为，因id != NULL恒为UNKNOWN，致整个AND表达式为UNKNOWN而被WHERE过滤；NOT EXISTS通过行存在性判断天然规避NULL干扰。

NOT IN子查询遇到NULL就返回空结果，不是数据库出错，而是SQL标准强制要求的三值逻辑行为——只要子查询里有一个NULL，整个条件求值就是UNKNOWN，而WHERE只认TRUE。

NOT IN (a, b, NULL) 实际被展开成什么？

数据库会把 id NOT IN (1, 2, NULL) 等价重写为：id != 1 AND id != 2 AND id != NULL。其中 id != NULL 在SQL中永远不返回TRUE或FALSE，只返回UNKNOWN；而AND表达式中只要有一个UNKNOWN，整体就是UNKNOWN。WHERE子句过滤时，UNKNOWN和FALSE一样被丢弃，所以没一行能通过。

• 哪怕主表有明确不匹配的行（比如id = 100），它照样不会出现
• 子查询只返回一个NULL，就足以让整条语句“静默失效”
• 这个行为在MySQL、PostgreSQL、SQL Server、Oracle中完全一致，不是某家的bug

为什么 NOT EXISTS 能绕过这个问题？

NOT EXISTS 不做值比较，只判断子查询是否「返回至少一行」。NULL值不影响行是否存在——只要关联条件能命中某行，就算有结果；没命中，就是空集。所以它天然免疫NULL干扰。

• 必须写成相关子查询，例如：NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
• 错误写法是常量子查询：NOT EXISTS (SELECT 1 FROM orders WHERE user_id = 101)，这会失去关联语义
• 原NOT IN子查询里的其他条件（如status = 'failed'）必须一并挪进NOT EXISTS的WHERE中，否则逻辑偏移

LEFT JOIN + IS NULL 方案最容易在哪两个地方写错？

这个方案把「不在集合中」转译为「左连接失败」，但实操中常因细节翻车：

• ON条件写错：比如漏掉表别名，写成o.user_id = user_id而非o.user_id = u.id，可能触发全表扫描
• 把本该在ON里的关联条件错放到WHERE：例如WHERE o.user_id IS NULL AND o.status = 'failed'，会导致LEFT JOIN退化为INNER JOIN，丢失预期语义
• 右表有重复匹配行时，会产生笛卡尔膨胀；此时NOT EXISTS更安全

真正容易被忽略的点，不是语法怎么写，而是业务语义里那些没明说的“空值含义”——比如字段为NULL，到底是“尚未创建”，还是“已删除”，还是“数据异常”？没理清这个，NOT EXISTS写得再对也查不准。