NOT IN 遇 NULL 失效是 SQL 三值逻辑必然结果；应改用 NOT EXISTS 或显式过滤 NULL（WHERE col IS NOT NULL）；反向条件优先转为正向表达，避免逻辑错误与索引失效。
WHERE NOT IN 遇到 NULL 就失效，怎么办
直接说结论：NOT IN 子查询只要返回任意一个 NULL，整条语句就查不出任何结果。这不是 bug，是 SQL 三值逻辑（true/false/unknown）的必然表现。
比如你想排除用户表中某些 user_id，但子查询里混进了 NULL（常见于左连接后取字段、或字段本身允许为空）：
SELECT * FROM users WHERE user_id NOT IN (SELECT banned_id FROM bans);
一旦 bans.banned_id 有 NULL，user_id NOT IN (1, 2, NULL) 对所有行都判为 unknown，被当成 false 过滤掉。
- 用
NOT EXISTS替代，它不关心子查询是否含NULL，只看是否存在匹配行 - 如果坚持用
NOT IN，必须显式过滤掉NULL：SELECT banned_id FROM bans WHERE banned_id IS NOT NULL -
NOT EXISTS通常也更快，尤其子查询结果集大时，因为它可以短路（找到一个匹配就停）
想排除多条件组合，别堆 NOT + AND
写成 WHERE NOT (status = 'deleted' AND created_at 看似合理，但实际排除的是「同时满足两个条件」的记录，不是你想要的「只要满足任一条件就排除」。
真正想表达“排除已删除的，或排除太老的”，逻辑上是 WHERE status != 'deleted' AND created_at >= '2020-01-01' —— 把反向过滤转成正向保留条件，更直白、不易错。
- 反向逻辑嵌套越深（比如
NOT (A AND (B OR C))），越容易漏括号或搞反德摩根律 - 优先把业务意图翻译成“我要什么”，而不是“不要什么”；数据库优化器对正向条件也更容易走索引
- 如果必须用
NOT，用NOT IN/NOT EXISTS比NOT + 复合表达式更可控
LIKE 取反时通配符和空值要单独处理
WHERE name NOT LIKE '%test%' 看起来能排除含 test 的名字，但它会漏掉 name IS NULL 的行 —— 因为 NULL LIKE ... 永远是 unknown，被过滤掉。
如果你的业务要求“所有非 test 名字 + 空名字都要保留”，就得拆开写：
WHERE name NOT LIKE '%test%' OR name IS NULL
-
NOT LIKE不等于 “不是 like”，它只是对LIKE结果取反，而NULL导致整个比较失效 - 同样道理，
!=或<>对NULL也无效，需要额外加IS NULL判断 - 如果字段有默认值（比如空字符串
''），也要确认它是否该被包含在“排除范围”里，NOT LIKE对''是正常计算的
用 LEFT JOIN + IS NULL 做反向关联过滤，注意 ON 和 WHERE 的区别
想查“没下过订单的用户”，常见写法是 LEFT JOIN orders ON users.id = orders.user_id WHERE orders.id IS NULL。这里 IS NULL 必须放在 WHERE，不能塞进 ON 条件里。
如果写成 LEFT JOIN orders ON users.id = orders.user_id AND orders.status != 'cancelled'，那 IS NULL 判断的是“没有非 cancelled 订单的用户”，不是“完全没有订单的用户”—— 关联逻辑被悄悄改写了。
-
ON控制“怎么连”，WHERE控制“连完怎么筛”，反向过滤的关键判断永远在WHERE - 多个反向条件（比如“没订单”且“没投诉”）适合用多个
LEFT JOIN + IS NULL，比写超长NOT EXISTS更易读 - 记得给关联字段建索引，否则
IS NULL判断可能触发全表扫描
反向过滤最麻烦的从来不是语法，而是隐式 NULL 和三值逻辑带来的“看起来对、跑出来空”的情况。每次写完 NOT 类条件，都该手动代入一条含 NULL 的数据试试结果。
