not in遇null返回空结果是sql三值逻辑必然现象；因id != null恒为unknown，致整个条件失效，应优先用带关联条件的not exists替代。
NOT IN遇到NULL为什么会返回空结果
当子查询结果中包含NULL时，NOT IN整个条件会恒为UNKNOWN，导致WHERE过滤后无任何行匹配——这不是bug，是SQL三值逻辑（TRUE/FALSE/UNKNOWN）的必然结果。比如WHERE id NOT IN (1, 2, NULL)等价于id != 1 AND id != 2 AND id != NULL，而id != NULL永远不成立（必须用IS NOT NULL判断）。
用NOT EXISTS替代NOT IN是最稳妥的做法
NOT EXISTS天然规避NULL陷阱，因为它只关心子查询是否返回行，不依赖值比较逻辑。写法上需注意关联条件不能漏：
SELECT * FROM orders o
WHERE NOT EXISTS (
SELECT 1 FROM customers c
WHERE c.id = o.customer_id
AND c.status = 'inactive'
);
- 子查询里必须有
WHERE关联主表字段（如c.id = o.customer_id），否则变成全表扫描+笛卡尔积 - 子查询中
SELECT 1比SELECT *更清晰，也避免无意中引用了可能为NULL的列 - 如果原
NOT IN子查询本就含NULL（比如SELECT manager_id FROM employees），直接换NOT EXISTS就能绕过问题
如果坚持用IN/NOT IN，必须显式过滤NULL
只有当你确认子查询结果集可控、且性能敏感（比如小表+索引好）时，才考虑加IS NOT NULL条件：
SELECT * FROM products WHERE category_id NOT IN ( SELECT category_id FROM categories WHERE category_id IS NOT NULL );
- 这个写法仅在子查询本身可能返回
NULL时才需要；如果子查询来自PRIMARY KEY或NOT NULL列，可省略 - 注意：
NOT IN (SELECT ... WHERE x IS NOT NULL)仍不如NOT EXISTS语义清晰，且在某些数据库（如PostgreSQL）中优化器可能无法有效利用索引 - 别写成
NOT IN (SELECT COALESCE(category_id, -1) ...)——人为替换NULL会污染业务逻辑，且-1可能真是合法值
MySQL和PostgreSQL在NULL处理上没有本质区别
有人以为MySQL对NOT IN更“宽容”，其实不然。只要子查询返回NULL，所有标准SQL数据库（包括MySQL 8.0+、PostgreSQL、SQL Server、Oracle）都会让整条NOT IN表达式结果为UNKNOWN。验证方法很简单：
SELECT 1 WHERE 1 NOT IN (1, NULL); -- 所有数据库都返回空结果集
- 不要依赖数据库版本或方言来“修复”这个问题
- 用
EXPLAIN看执行计划时，NOT EXISTS通常能走半连接（semi-join）优化，而带IS NOT NULL的NOT IN可能触发临时表或全表扫描 - 最易被忽略的是子查询里嵌套的
LEFT JOIN或COALESCE——它们可能悄悄引入NULL，却不在你肉眼可见的SELECT列表里
