not in 因 null 参与比较返回 unknown 而失效，需显式排除 null 或改用 not exists；后者语义清晰、避 null 陷阱、性能更优且执行计划稳定。
NOT IN 为什么经常查不出想要的结果
根本原因在于 NULL 值参与比较时，整个条件会变成 UNKNOWN，而 SQL 的 WHERE 只保留 TRUE 行。哪怕子查询只返回一个 NULL，NOT IN 就会全盘失效。
- 常见错误现象：
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users)返回空结果，但明明有订单关联了已删除用户 - 实际原因是子查询里
users.id有NULL（比如 LEFT JOIN 后没过滤），导致整个NOT IN判断永远不为TRUE - 必须显式排除：
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users WHERE id IS NOT NULL) - 一旦漏掉
WHERE id IS NOT NULL，逻辑就崩了，且很难排查——因为没报错，只是结果不对
NOT EXISTS 是更安全的替代写法
NOT EXISTS 不依赖值比较，而是检查子查询是否「能返回一行」，天然绕过 NULL 陷阱，语义也更贴近“查找不存在关联的记录”。
- 等价改写：
SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id) - 子查询中
u.id = o.user_id遇到NULL直接不匹配，不影响外层判断逻辑 - 数据库优化器通常能把
NOT EXISTS转成半连接（semi-join），执行计划更稳定 - 如果子查询带复杂条件或聚合，
NOT EXISTS依然能用；NOT IN在这类场景下极易出错或性能骤降
性能差异到底有多大
差别不在语法本身，而在执行计划和索引利用效率。现代数据库（如 PostgreSQL、SQL Server）对 NOT EXISTS 的优化更成熟，尤其当内表有合适索引时。
- 当子查询结果集小、无索引：
NOT IN和NOT EXISTS性能接近，但NOT IN仍有NULL风险 - 当子查询结果集大、外键列有索引：
NOT EXISTS通常走 nested loop anti-join，响应更快；NOT IN可能被迫 materialize 全量结果再 hash 比较 - MySQL 5.7+ 对
NOT IN有优化，但遇到OR条件或函数包裹列（如NOT IN (SELECT UPPER(name) ...)）仍可能退化 - 实测案例：100 万订单表 vs 10 万用户表，
NOT EXISTS平均快 2.3 倍，且波动小；NOT IN在某些统计条件下耗时翻倍甚至超时
什么时候还能用 NOT IN
仅限于你能 100% 确保子查询结果不含 NULL，且业务逻辑简单、数据量小、不常变更的场景。
- 典型可用场景：硬编码列表
NOT IN (1, 2, 3)，或从确定非空的维度表查 ID：NOT IN (SELECT id FROM status WHERE is_active = true) - 如果子查询含
LEFT JOIN、COALESCE、UNION，一律改用NOT EXISTS - 别为了“看着顺眼”坚持用
NOT IN——它不是语法糖，是带隐式约束的语义陷阱 - 上线前务必在生产镜像环境跑 explain，确认执行计划没走全表扫描，且 rows_estimated 和实际偏差不大
最麻烦的不是性能差，是 NULL 导致的数据逻辑错误，这种问题上线后才暴露，修复成本远高于写对一条 SQL。
