not in 遇 null 失效是 sql 三值逻辑必然结果：id not in (1,2,null) 等价于 id≠1 and id≠2 and id≠null，而 id≠null 恒为 unknown，where 只保留 true，故全被过滤。

为什么 NOT IN 在 NULL 存在时会失效

当 NOT IN 子查询返回的结果里包含 NULL，整个条件会恒为 UNKNOWN，导致查不到任何行——这不是 bug，是 SQL 三值逻辑的必然结果。比如：WHERE id NOT IN (1, 2, NULL) 等价于 id != 1 AND id != 2 AND id != NULL，而 id != NULL 永远不成立。

用 LEFT JOIN + IS NULL 实现标准 ANTI JOIN

这是最通用、可读性好、且数据库兼容性强的写法，所有主流 SQL 引擎（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）都支持。

假设要从 orders 中排除所有有对应 returns 记录的订单：

SELECT o.* 
FROM orders o
LEFT JOIN returns r ON o.order_id = r.order_id
WHERE r.order_id IS NULL;

关键点：

• LEFT JOIN 保证左表所有行保留，右表匹配不到则全为 NULL
• WHERE r.order_id IS NULL 精准筛选出“右表无匹配”的行
• 务必用右表的 非空字段（如主键或带 NOT NULL 约束的列）判空，避免误筛
• 如果右表连接字段允许 NULL，r.order_id IS NULL 可能混入本就为 NULL 的脏数据，需提前过滤

EXISTS vs ANTI JOIN：性能与语义差异

NOT EXISTS 是另一种常用替代，它天然规避 NULL 问题，但和 ANTI JOIN 并非等价：

Toingg Ops Toolkit

一款AI音频处理工具，主要用于通过向 `toingg/make_campaign` API 发送 POST 请求，提交用户提供的 JSON 数据，创建并启动 Toingg 语音呼叫活动，适用于 Codex 将活动简报……，适合需要提升相关任务效率的用户。

下载

• NOT EXISTS 是半连接（semi-join），只关心“是否存在”，不拉取右表数据，通常更省资源
• LEFT JOIN + IS NULL 是完整连接，若右表有重复匹配，可能引发笛卡尔积膨胀（需加 DISTINCT 或预聚合）
• PostgreSQL 和 SQL Server 优化器常把两者转成相同执行计划；MySQL 5.7 前者更稳，8.0+ 差异极小
• 语义上：NOT EXISTS 更贴近“不存在满足条件的记录”，而 LEFT JOIN 更贴近“逐行尝试关联后落空”

MySQL 中 NOT IN 的坑与绕过技巧

MySQL 对 NOT IN 的处理尤其敏感，即使子查询里只是隐式含 NULL（比如某列有 NULL 值且未被 WHERE 过滤），也会静默失败。

安全写法只有两个：

• 用 LEFT JOIN + IS NULL（推荐，逻辑清晰）
• 强行清除 NULL：WHERE id NOT IN (SELECT id FROM t WHERE id IS NOT NULL)，但子查询变复杂，且无法利用 id 上的索引覆盖（因加了 WHERE 条件）

别依赖 SET sql_mode = 'STRICT_TRANS_TABLES' 来报错——它不会让 NOT IN 失效变报错，只是让其他问题更早暴露。

真正容易被忽略的是连接字段的类型一致性：如果 o.order_id 是 BIGINT，而 r.order_id 是 VARCHAR，隐式转换可能导致索引失效或意外匹配。检查执行计划里的 type 是否为 ref 或 eq_ref，而不是 ALL。