not in 遇到子查询返回 null 时结果为空，因 sql 三值逻辑使 column != null 恒为 unknown，导致整个表达式求值为 unknown 而被 where 过滤；其等价于 column != a and column != b and column != null。
NOT IN 遇到子查询返回 NULL 时查不出数据，不是 MySQL 的 bug，而是 SQL 标准的三值逻辑（TRUE/FALSE/UNKNOWN）在起作用——只要子查询里任意一行的比较字段为 NULL，整个 NOT IN 表达式就求值为 UNKNOWN，而 WHERE 只保留 TRUE 行，UNKNOWN 和 FALSE 都被过滤掉，结果自然为空。
NOT IN (a, b, NULL) 实际等价于什么
它会被数据库展开为一连串 AND 条件：
column != a AND column != b AND column != NULL
而 column != NULL 永远是 UNKNOWN（SQL 规定任何值与 NULL 比较都得 UNKNOWN），整个表达式因此变成 UNKNOWN。哪怕前两个条件都是 TRUE，也救不回来。
- 常见触发场景：
SELECT id FROM orders WHERE customer_id NOT IN (SELECT id FROM customers)，只要customers.id里有一条是NULL，整张orders表就查不到任何记录 - 你手动跑子查询能看到数据，但一塞进
NOT IN就“失效”，这不是执行慢，是逻辑直接被截断 -
EXPLAIN可能看起来正常（type: ref或index），但实际执行时优化器已放弃索引下推，转为全表扫描+逐行判断
为什么加索引也救不了 NOT IN
MySQL 优化器不敢对 NOT IN 下推索引，因为它无法保证在含 NULL 的情况下语义安全——索引查找依赖确定的等值或范围，而 NULL 让整个判断失去确定性。
-
key_len: NULL、Extra: Using where; Using join buffer是典型信号 - 即使
customers.id有索引，且你确认它非空，优化器仍可能退化为ALL扫描，尤其在 MySQL 5.6 或更低版本 - 字符集或类型不一致（比如一边是
VARCHAR(20)，一边是VARCHAR(50)）会触发隐式转换，进一步让索引失效
LEFT JOIN + IS NULL 写错就会更糟
这个方案本身能绕过 NULL 陷阱，但写法容错率极低，错一处就逻辑翻车或性能崩盘：
-
ON条件必须严格等值：a.uid = b.uid，不能写成a.uid = COALESCE(b.uid, -1)或加函数 - 子查询里的过滤条件（如
status = 'active'）必须挪进ON子句，写在最后的WHERE里会让LEFT JOIN变成INNER JOIN -
WHERE b.uid IS NULL是唯一合法写法；写成WHERE b.uid = NULL永远不成立 - 右表连接字段若没索引，或允许
NULL且未在子查询中显式过滤（WHERE uid IS NOT NULL），照样全表扫
NOT EXISTS 是更稳的选择，但细节决定成败
它不比值，只判“是否存在匹配行”，天然免疫 NULL 干扰，但必须是相关子查询，且条件平移要完整：
- 错误写法：
NOT EXISTS (SELECT 1 FROM orders WHERE customer_id = 101)—— 这是常量子查询，和外层无关 - 正确写法：
NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = u.id)—— 必须引用外层表字段 - 原
NOT IN子查询中的其他条件（如created_at > '2025-01-01'）必须一并写进子查询的WHERE，漏掉就语义偏移 - 关联字段类型必须一致；
INT对VARCHAR会导致隐式转换，索引失效
真正容易被忽略的点，从来不是“该用哪个语法”，而是改写后是否把原子子查询里的所有过滤条件、字段约束、索引状态都同步迁移过去——少一个，就可能查出错数据，或者慢得更离谱。
