NOT IN遇NULL失效是SQL三值逻辑标准行为，因id NOT IN (a,b,NULL)等价于id!=a AND id!=b AND id!=NULL，其中id!=NULL恒为UNKNOWN，致整个条件被WHERE过滤；应改用NOT EXISTS或LEFT JOIN IS NULL。
NOT IN 基本写法和常见失效场景
直接用 NOT IN 排除指定值，语法简单但极易出错。最典型问题是：只要子查询或列表中包含 NULL，整个 NOT IN 判断会返回空结果集——不是没匹配上，而是逻辑判定直接失效。
比如：SELECT * FROM users WHERE id NOT IN (1, 2, NULL)，这条语句查不到任何记录，因为 id = 3 时，3 NOT IN (1, 2, NULL) 的结果是 UNKNOWN（SQL 三值逻辑），而 WHERE 只接受 TRUE。
- 永远先确认右侧列表或子查询是否可能含
NULL - 若来自表查询，加
WHERE column IS NOT NULL过滤 - 若为字面量列表，手动剔除
NULL，别写成(1, 2, NULL)
替代方案：用 NOT EXISTS 替代 NOT IN 子查询
当右侧是子查询（如 SELECT id FROM banned_users）时，NOT EXISTS 更安全、性能通常也更好，尤其在大数据量下。
NOT IN 要求子查询结果全部加载并去重，而 NOT EXISTS 是关联驱动，可利用索引提前终止。
- 写法示例：
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM banned_users b WHERE b.user_id = u.id) - 注意子查询里必须关联外层表（如
b.user_id = u.id），否则变成常量子查询，逻辑错误 - 如果子查询无关联条件，
NOT EXISTS永远返回FALSE或TRUE，失去意义
小范围排除用 NOT IN 字面量，但要严格校验 NULL
只排除几个已知 ID，比如 status NOT IN ('draft', 'pending')，这种用法没问题——字符串字面量不含 NULL。
但换成数值或从变量拼接时风险陡增。例如后端拼 SQL：... NOT IN (" + ids.join(',') + ")"，若 ids 数组含空值或 null 元素，就引入了隐式 NULL。
- 拼接前过滤掉空值：
ids.filter(x => x != null && x !== '') - 用参数化查询（如 PostgreSQL 的
NOT IN (UNNEST($1::int[]))）避免字符串拼接 - MySQL 8.0+ 支持
MEMBER OF，但兼容性差，不建议替换NOT IN主流用法
NOT IN 和 LEFT JOIN / IS NULL 的性能与可读性权衡
有人倾向用 LEFT JOIN ... WHERE right_table.id IS NULL 实现“排除”，这在某些旧版 MySQL 或需要复用 JOIN 条件时更直观。
但它会强制全表连接，若右表无索引或数据量大，性能可能比 NOT EXISTS 差；且语义不如 NOT EXISTS 直接表达“不存在”。
- 仅当已有 JOIN 上下文（如同时要取右表其他字段）才考虑复用
LEFT JOIN - 单独做排除逻辑时，优先选
NOT EXISTS，它明确、安全、多数引擎优化成熟 - PostgreSQL 对
NOT IN的 NULL 处理有警告提示，但 MySQL 完全静默，容易线上踩坑
实际用的时候，别只盯着“怎么写”，重点盯住数据里有没有 NULL、子查询会不会返回空行、以及执行计划里是不是真用了索引。这些细节比语法本身更容易决定结果对不对。
