应优先用 not exists 替代 not in，因其避免 null 导致结果为空的逻辑陷阱，支持短路执行、更易利用索引，且语义清晰可靠；left join ... is null 是有效替代方案，但需注意关联条件与 null 判断位置。
直接结论：用 NOT EXISTS 替代 NOT IN，尤其是子表字段可能含 NULL、数据量大或主表有索引时，性能更稳、语义更可靠。
为什么 NOT IN 在实际中经常出问题
NOT IN 看似最直白，但它的逻辑陷阱和性能短板在生产环境里很常见：
- 只要子查询结果里任意一个值是
NULL，整个NOT IN条件就恒为UNKNOWN，最终查不到任何数据（SQL 的三值逻辑） - 数据库优化器很难对
NOT IN (子查询)做有效索引下推，容易触发全表扫描 - 子查询返回大量值时，
NOT IN会把结果集全部加载进内存做哈希比对，内存和 CPU 开销陡增 - 即使子查询加了索引，
NOT IN也可能因执行计划选择不当而失效
NOT EXISTS 的执行逻辑和写法要点
NOT EXISTS 不关心子查询返回什么，只判断“有没有匹配行”。它天然支持短路：一找到匹配就停，不扫全表。关键在于关联条件必须写对：
- 子查询里必须引用主表的列（如
u.id），否则变成无关联子查询，结果恒为FALSE或TRUE - 子查询中
SELECT后面写1、*或任意常量都一样，不影响性能，推荐用SELECT 1表意清晰 - 主表字段和子表字段类型要严格一致，否则隐式转换可能导致索引失效（比如
INT对比VARCHAR）
典型写法示例：
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
什么时候该考虑 LEFT JOIN ... IS NULL
当你要排除的值来自一个固定小列表，或者你已经建好了排除值表（比如 excluded_values），LEFT JOIN 可能比 NOT EXISTS 更快，尤其在 MySQL 8.0+ 或 PostgreSQL 中，优化器对这类连接识别更好：
- 避免子查询嵌套，执行计划更透明，DBA 容易调优
- 如果排除值表本身有主键或唯一索引，
JOIN能走索引查找，效率接近NOT EXISTS - 但要注意：右表别名必须在
WHERE中判IS NULL，不能写成= NULL
示例：
SELECT u.* FROM users u LEFT JOIN excluded_values e ON u.status = e.val WHERE e.val IS NULL;
容易被忽略的细节和复杂点
真正卡住人的往往不是语法，而是这些隐性条件：
-
NOT EXISTS子查询里如果用了OR、函数或复杂表达式，可能让优化器放弃使用索引 - 主表和子表的字符集/排序规则不一致时，即使字段类型相同，也可能导致关联失败或全表扫描
- 某些旧版 MySQL（如 5.6）对
NOT EXISTS的优化不如 PostgreSQL 或 SQL Server，建议实测执行计划 - 如果子表数据极少（比如就 3 条），
NOT IN和NOT EXISTS性能差异几乎为零，没必要强行改写
