not in遇null返回空结果是sql三值逻辑标准行为，因id not in (1,2,null)等价于id!=1 and id!=2 and id!=null，而id!=null恒为unknown，致整个条件为unknown被where过滤；应改用not exists或left join+is null。
NOT IN 遇 NULL 为什么整条查询返回空结果
因为 NOT IN 在子查询结果中包含 NULL 时，整个 WHERE 条件求值为 UNKNOWN，而 SQL 的 WHERE 子句只保留 TRUE 行——UNKNOWN 和 FALSE 全部被过滤掉，结果集自然为空。
这不是数据库 bug，也不是某家厂商的缺陷，而是 SQL-92 标准定义的三值逻辑（TRUE/FALSE/UNKNOWN）在严格执行。
-
id NOT IN (1, 2, NULL)实际等价于：id != 1 AND id != 2 AND id != NULL -
id != NULL永远是UNKNOWN，而AND表达式中只要有一个UNKNOWN，整体就是UNKNOWN - 哪怕主表有明确不匹配的行（比如
id = 100），它照样不会出现 - 子查询只返回一个
NULL，就足以让整条语句“静默失效”
NOT EXISTS 为什么能绕过 NULL 问题
NOT EXISTS 不做值比较，只判断子查询是否「返回至少一行」。只要关联条件能命中某行，就算有结果；没命中，就是空集。所以 NULL 值不影响行是否存在，天然免疫 NULL 干扰。
但必须写成相关子查询，否则逻辑就错了：
- 错误写法（常量子查询，无关联）：
NOT EXISTS (SELECT 1 FROM orders WHERE customer_id = 101) - 正确写法（带外层引用）：
NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id) - 原
NOT IN子查询里的其他条件（如status = 'failed'）必须一并挪进子查询的WHERE中，否则语义偏移 - 子查询里用
SELECT 1就够了，别写SELECT *或具体字段
LEFT JOIN + IS NULL 方案要注意什么
这个方案把「不在集合中」转译为「左连接失败」，语义直观，但容易在两个地方出错：
-
ON条件写错（比如漏掉表别名，写成o.user_id = user_id而非o.user_id = u.id），可能触发全表扫描 - 把本该在
ON里的关联条件错放到WHERE，导致LEFT JOIN变成INNER JOIN，丢失预期语义 - 右表有重复匹配行时，会产生笛卡尔膨胀；此时
NOT EXISTS更安全 - 示例正确写法：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL
如果非要保留 NOT IN，该怎么补救
唯一安全的补救方式是在子查询中显式过滤 NULL：WHERE col IS NOT NULL。但这会改变原始语义：
- 你本想排除所有匹配值（含
NULL），现在只排除非空匹配值 - 若业务上
NULL有明确含义（比如“未知部门”），硬过滤可能掩盖数据质量问题 - 子查询若本身返回空集（0 行），
NOT IN反而会返回全部主表数据——这个反直觉行为和NULL无关，但常被一起误判 - 真正容易被忽略的点不是语法怎么写，而是：改用
NOT EXISTS后仍出错，往往是因为忘了把原子查询的过滤条件（比如时间范围、状态码）一并挪进子查询的WHERE里
