not in 遇子查询含 null 时必然无结果，因三值逻辑下 id != null 恒为 unknown，致整个 and 条件为 unknown 被过滤；not exists、left join + is null 或子查询加 is not null 过滤可规避。
NOT IN 遇到子查询返回 NULL，必然查不出任何数据——这不是数据库 bug，是 SQL-92 标准强制要求的三值逻辑行为。
NOT IN 实际被展开成 AND 判断，而 != NULL 永远是 UNKNOWN
当你写 WHERE id NOT IN (SELECT user_id FROM orders)，数据库不是“聪明地跳过 NULL”，而是严格等价于：
WHERE id != value1 AND id != value2 AND id != NULL
其中 id != NULL 在 SQL 中永远返回 UNKNOWN（不是 TRUE，也不是 FALSE）。而 AND 表达式只要有一个 UNKNOWN，整体就是 UNKNOWN。WHERE 只保留 TRUE 行，UNKNOWN 和 FALSE 全部被过滤掉。
哪怕子查询只返回一行 NULL，整条语句就“静默失效”；哪怕主表有 10 万行匹配不上，也一条不出现。
为什么 NOT EXISTS 能绕过这个问题
NOT EXISTS 不做值比较，只判断子查询是否返回至少一行记录。它完全不关心字段值是不是 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)（用外层别名c关联）
原 NOT IN 子查询里的其他条件（比如 status = 'paid'）必须一并挪进 NOT EXISTS 的 WHERE 中，否则逻辑偏移。
LEFT JOIN + IS NULL 看似直观，但 ON 和 WHERE 容易写反
这个方案把“不在集合中”翻译为“左连接失败”，语义清晰，但极易因条件位置出错导致结果错误：
- 关联条件必须写在
ON里，比如ON u.id = o.user_id；如果错写进WHERE，LEFT JOIN就退化成INNER JOIN - 右表字段允许
NULL或没索引时，可能触发全表扫描 + 临时表 - 一对多关系下不加
DISTINCT或GROUP BY，会因笛卡尔积重复计数
正确写法示例：SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL
硬加 WHERE col IS NOT NULL 是最直白的补救，但会掩盖数据问题
如果非要用 NOT IN，唯一安全方式是在子查询里显式过滤：
WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL)
但这带来两个隐性代价：
- 业务上
user_id IS NULL可能代表“未知来源订单”，硬过滤等于丢掉这部分语义 - 优化器可能放弃索引下推，尤其在 MySQL 中，
NOT IN本身就不容易走索引
真正容易被忽略的是：子查询返回空集（0 行）时，NOT IN 反而会返回全部主表数据——这个反直觉行为和 NULL 问题无关，但排查时经常被混为一谈。
