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、子查询会不会返回空行、以及执行计划里是不是真用了索引。这些细节比语法本身更容易决定结果对不对。