left join + is null更可靠，因not in遇b表null时整行判为unknown致结果为空，而left join仅判断连接后右表字段是否为null，语义清晰且不受原始null干扰。

为什么LEFT JOIN + IS NULL比NOT IN更可靠

当你要找出「在A表中存在、但不在B表中出现」的记录时，NOT IN看似简洁，但只要B表的关联字段含NULL，整个查询结果就变成空——这是SQL三值逻辑（TRUE/FALSE/UNKNOWN）导致的隐性陷阱。而LEFT JOIN ... IS NULL绕过了NULL参与比较的过程，只依赖连接结果是否为NULL行，语义清晰且行为稳定。

• NOT IN (SELECT id FROM b)：一旦子查询返回任意NULL，整条WHERE条件求值为UNKNOWN，该行被过滤掉
• LEFT JOIN b ON a.id = b.id WHERE b.id IS NULL：只关心连接后b.id是否为NULL，不受b表原始数据中NULL值干扰
• 多数主流数据库（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）对这种写法有较好优化，执行计划常能走Hash Anti Join或Merge Anti Join

正确写法：LEFT JOIN后必须用右表字段IS NULL

关键点在于IS NULL必须作用于JOIN右侧表（即被排除的表）的**非空约束字段**，通常是主键或带NOT NULL的关联列。如果误用左表字段或右表允许NULL的字段，结果会出错。

• ✅ 正确：LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL（假设orders.id是主键，不可能为NULL）
• ❌ 错误：LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL（o.user_id本身可能为NULL，无法区分是没匹配上还是匹配上了但值为NULL）
• ❌ 错误：LEFT JOIN orders o ON u.id = o.user_id WHERE u.id IS NULL（左表字段永远非NULL，条件恒假）

示例（查所有没下过单的用户）：

SELECT u.* 
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

性能敏感时要注意索引和驱动表顺序

数据库优化器通常会把小表作为驱动表（LEFT JOIN左边），但如果你明确知道左表远大于右表，某些引擎（如MySQL）可能不会自动选择最优路径。此时需确认ON条件字段是否有索引，以及实际执行计划是否走了type=ref或index而非ALL。

• 确保右表关联字段（如orders.user_id）有索引，否则LEFT JOIN会触发全表扫描
• 若左表极大且右表极小，可考虑用NOT EXISTS替代（它天然以右表为驱动，有时更高效）
• 在PostgreSQL中，EXPLAIN ANALYZE里看到Hash Anti Join通常比Nested Loop Left Join快得多

遇到外键缺失或空字符串干扰怎么办

真实业务中，user_id字段可能存空字符串''或非法值（如'unknown'），这些不会被NULL捕获，却会让LEFT JOIN误匹配。这不是语法问题，而是数据质量漏洞。

• 先检查右表脏数据：SELECT COUNT(*) FROM orders WHERE user_id = '' OR user_id IS NULL OR user_id NOT IN (SELECT id FROM users)
• 若不能清洗数据，可在ON条件中加固：LEFT JOIN orders o ON u.id = o.user_id AND o.user_id != '' AND o.user_id IS NOT NULL
• 注意：加AND条件在ON里是合理的（影响连接逻辑），但如果写在WHERE里，会把NULL行过滤掉，破坏排他性语义

真正容易被忽略的是数据一致性前提——LEFT JOIN + IS NULL只保证「当前快照下无匹配」，不防并发插入。如果业务要求强排他性，得配合应用层锁或数据库唯一约束，而不是只靠查询逻辑。