not in遇null导致结果为空，因三值逻辑下条件恒为unknown而被where过滤；应改用not exists或left join+is null，并确保子查询关联正确、索引有效。
WHERE ID NOT IN 会意外漏掉 NULL 导致结果为空
当子查询或列表中包含 NULL，NOT IN 整个条件直接返回空结果集——不是没匹配上，而是逻辑判断变成未知（UNKNOWN），被当作 FALSE 过滤掉了。这是最常踩的坑。
- 比如：
SELECT * FROM users WHERE id NOT IN (1, 2, NULL)→ 查不到任何行，哪怕 id=3、4 都存在 - 原因：SQL 中任意值与
NULL比较都为UNKNOWN，而WHERE只接受TRUE - 检查子查询是否可能返回
NULL：用SELECT COUNT(*) FROM xxx WHERE yyy IS NULL快速验证
替代方案：用 NOT EXISTS 比 NOT IN 更安全
NOT EXISTS 不受 NULL 影响，语义清晰，且在大多数数据库中执行计划更稳定。
- 写法示例：
SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM banned_users b WHERE b.id = u.id );
- 注意子查询里必须关联外层表（如
b.id = u.id），否则变成全量排除 - 如果只是排除几个固定 ID，且确认无
NULL，NOT IN (1, 2, 3)简洁有效；但一旦涉及子查询，优先选NOT EXISTS
用 LEFT JOIN + IS NULL 也能等价实现
适合需要同时访问被排除表其他字段，或想明确看到“匹配失败”的中间状态。
- 示例：
SELECT u.* FROM users u LEFT JOIN banned_users b ON u.id = b.id WHERE b.id IS NULL;
- 性能上，若
banned_users.id有索引，和NOT EXISTS差距不大；但若没索引，LEFT JOIN可能更慢（需构建临时连接结果） - 别漏写
WHERE b.id IS NULL—— 否则查出来的是全部用户，包括被排除的
MySQL 8.0+ 和 PostgreSQL 对 NOT IN 的优化差异
新版数据库对 NOT IN 做了部分优化，但行为不一致，不能依赖。
- MySQL 8.0+ 在子查询明确加
WHERE col IS NOT NULL后，会自动优化掉NULL判断逻辑 - PostgreSQL 仍严格遵循三值逻辑，
NULL出现即失效，不自动过滤 - 跨数据库迁移时，用
NOT EXISTS是最稳妥的选择，语义统一、行为确定
实际写的时候，先盯住子查询会不会吐 NULL；只要不确定，就别碰 NOT IN。
