NOT IN 查询结果为空通常因子查询含NULL值导致全行被过滤；应改用NOT EXISTS或显式排除NULL，并确保类型一致、字段有索引。
NOT IN 查询结果为空，但明明有不匹配的数据
这通常是因为 NOT IN 子查询中包含 NULL 值。SQL 中任意值与 NULL 做比较（包括 !=、NOT IN）都会返回 UNKNOWN，而 WHERE 只保留 TRUE 结果，导致整行被过滤掉。
- 检查子查询是否可能返回
NULL：SELECT user_id FROM orders WHERE status = 'cancelled'若某记录user_id为NULL，就会“静默破坏”整个NOT IN - 安全写法是显式排除
NULL：SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL) - 更推荐用
NOT EXISTS替代，它天然对NULL不敏感，语义也更清晰
用 NOT EXISTS 替代 NOT IN 更可靠
NOT EXISTS 不依赖值比较，而是检查子查询是否返回行，因此完全规避 NULL 导致的空结果问题，且在大多数数据库中执行计划更稳定。
- 等价改写示例：
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) - 注意关联条件必须写全（如
o.user_id = u.id），漏写会变成笛卡尔积 + 永远为真 - 若子查询有复杂过滤（如
WHERE o.status = 'shipped'），直接加在子查询内即可，不影响外层逻辑
NOT IN 在大数据量下性能突然变差
当右操作数（括号内的子查询或列表）结果集较大时，部分数据库（如 MySQL 5.7 及更早版本）无法有效使用索引，甚至退化为嵌套循环扫描。
- 如果子查询返回上万行，优先考虑
NOT EXISTS或LEFT JOIN ... IS NULL - 确保子查询中的关联字段（如
user_id）在目标表上有索引；否则NOT IN可能触发全表扫描 - 避免把
NOT IN写成字面量列表（如NOT IN (1,2,3,...,1000)），超过几百项就应转为临时表或 CTE
PostgreSQL / SQL Server 中 NOT IN 的额外行为差异
PostgreSQL 对 NOT IN 的 NULL 处理和标准一致（即遇 NULL 整体失效），但 SQL Server 在某些兼容模式下可能表现不同；更重要的是类型隐式转换风险。
- 若左值是
VARCHAR，右子查询返回INT，SQL Server 可能强制将所有左值转为INT，导致截断或转换错误（如'abc'→ 转换失败） - PostgreSQL 要求两侧类型严格兼容，不匹配会报错：
operator does not exist: text = integer - 统一做法：显式类型转换，例如
id NOT IN (SELECT CAST(user_id AS BIGINT) FROM orders)
实际用的时候，NULL 和类型匹配这两个点最容易被跳过，一出问题又很难一眼定位。
