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与否。
