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) = '2024-01-01'）或隐式类型转换（比如 user_id 是字符串但子查询返回数字），这会让所有方案都失效索引——先解决这类基础问题，再谈 NOT IN 与否。
