not in遇null返回空结果是sql三值逻辑所致，因id != null恒为unknown被where过滤；安全做法是子查询加is not null过滤或改用not exists。
NOT IN 在存在 NULL 时会完全失效，返回空结果集——这是最常踩的坑，不是语法错，是逻辑陷阱。
为什么 NOT IN 查不到数据，但手动写 != 就行？
根本原因是 SQL 对 NULL 的三值逻辑（TRUE/FALSE/UNKNOWN）处理：NOT IN 子查询只要返回任意一个 NULL，整个条件就判定为 UNKNOWN，而 WHERE 只保留 TRUE 行。
- 假设子查询返回
(1, 2, NULL)，那么id NOT IN (1, 2, NULL)等价于id != 1 AND id != 2 AND id != NULL - 其中
id != NULL永远不成立（因为 NULL 不能用 = 或 != 判断），整条表达式结果为 UNKNOWN - 最终没有一行满足 WHERE 条件，结果为空
如何安全地用 NOT IN 排除业务范围？
必须确保子查询结果不含 NULL，且明确知道哪些字段参与排除逻辑。
- 在子查询中加
WHERE column_name IS NOT NULL过滤掉空值 - 若排除的是多字段组合（如订单状态 + 类型），需用
NOT EXISTS替代，NOT IN不支持多列 - 如果业务上“未填写”和“无效值”都算要排除的范围，别依赖字段是否为 NULL，改用显式枚举：
status NOT IN ('draft', 'pending', 'archived')
示例：
SELECT * FROM orders WHERE order_id NOT IN ( SELECT order_id FROM refunds WHERE processed_at IS NOT NULL -- 关键：排除 NULL );
NOT IN vs NOT EXISTS 性能与语义差异
NOT IN 要求子查询先执行并去重生成列表，再做哈希匹配；NOT EXISTS 是关联驱动，对主表每行执行一次子查询，适合大表排除小集合。
- 当子查询结果少、主表大，
NOT IN可能更快（尤其有索引时） - 当子查询可能含 NULL、或需关联主表字段（如排除“同一用户下的历史订单”），必须用
NOT EXISTS - MySQL 8.0+ 对
NOT IN有优化，但 PostgreSQL 和 Oracle 仍严格遵循三值逻辑
替代写法示例：
SELECT * FROM orders o
WHERE NOT EXISTS (
SELECT 1 FROM refunds r
WHERE r.order_id = o.order_id
AND r.processed_at IS NOT NULL
);
真正麻烦的不是写法，而是业务语义里那些没明说的“空值含义”——比如 status 字段为 NULL，到底是“尚未创建”，还是“已删除”，还是“数据异常”？没理清这个，NOT IN 写得再对也查不准。
