17370845950

NOT IN 遇 NULL 会返回空集，因 value != NULL 恒为 UNKNOWN；应过滤 NULL、改用 NOT EXISTS 或 LEFT JOIN ... IS NULL；子查询可含重复值但需防性能问题；索引与类型一致是前提。

NOT IN 遇到 NULL 会整个失效

这是最常踩的坑：NOT IN 子查询只要返回任意一个 NULL，整条语句结果就变成空集（0 行），不是逻辑错误，而是 SQL 标准定义的行为。因为 value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而 value != NULL 永远是 UNKNOWN，导致整个条件不成立。

实操建议：

• 强制过滤子查询中的 NULL：

  SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users WHERE id IS NOT NULL);

• 改用 NOT EXISTS（天然规避 NULL 问题）：

  SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id);

• 用 LEFT JOIN ... IS NULL 替代，语义清晰且性能可控：

  SELECT o.* FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL;

NOT IN 子查询不能有重复值？其实可以，但没必要

NOT IN 对子查询结果是否去重没有强制要求，MySQL 会自动忽略重复值（本质是集合语义）。但重复本身可能暴露设计问题或拖慢子查询执行。

常见场景：

• 子查询含 GROUP BY 或 DISTINCT：合理，尤其当关联表一对多时防止膨胀
• 子查询无去重却返回大量重复 ID：说明 JOIN 条件松散或缺少索引，应先优化子查询本身
• 子查询结果超 1000 行：MySQL 可能放弃使用索引，转为全表扫描外层表；此时 NOT EXISTS 或 LEFT JOIN 更稳

性能差？大概率是没走索引或数据量失衡

NOT IN 的执行计划容易误判。MySQL 常把子查询结果物化成临时表，若外层表大、子查询结果也大，就会触发嵌套循环 + 全量比对。

检查和优化方法：

• 用 EXPLAIN 看 type 是否为 ALL 或 index，Extra 是否出现 Using where; Using join buffer
• 确保外层字段（如 orders.user_id）和子查询字段（如 users.id）都有索引，且类型严格一致（比如都是 INT UNSIGNED，别一边 SIGNED 一边 UNSIGNED）
• 子查询若涉及多表，优先用覆盖索引减少回表；外层若带复杂 WHERE 条件，考虑把 NOT IN 拆成先查出排除 ID 列表，再用 WHERE id NOT IN (1,2,3...)（仅限 ID 数量可控，比如几百以内）

替代方案选哪个？看数据分布和维护成本

没有银弹。三者行为一致（排除存在匹配的记录），但执行路径和稳定性不同：

• NOT IN：语法最简，但对 NULL 敏感、优化器易误判，适合子查询小且确定无 NULL
• NOT EXISTS：语义明确、不受 NULL 影响、通常走半连接优化，推荐作为默认选择
• LEFT JOIN ... IS NULL：可读性最强，便于加中间字段调试，但需注意外层 SELECT 别漏掉 DISTINCT（如果关联一对多）

真正容易被忽略的是：子查询里用了函数（比如 WHERE DATE(created_at) = '2025-01-01'）或隐式类型转换（比如 user_id 是字符串但子查询返回数字），这会让所有方案都失效索引——先解决这类基础问题，再谈 NOT IN 与否。