left join后where b.id is null过滤的是join失败产生的null行，而非b表原存的null值；not in遇null会因三值逻辑返回空，而该模式逻辑稳定、不受b表null影响。
LEFT JOIN后WHERE B.id IS NULL到底在过滤什么
它不是在“筛选A表独有的记录”，而是在LEFT JOIN生成的临时结果集上，挑出那些B表字段全为NULL的行。关键点在于：这个NULL来自JOIN失败（即A中某行在B中无匹配），不是B表本身存了NULL值。
常见误判是以为只要B表有NULL就命中——其实不会。如果B表某行id本身就是NULL，而A表某行恰好也NULL（假设ON条件允许），那这行会被连上，WHERE B.id IS NULL反而会把它错误剔除。
为什么不能用NOT IN替代
NOT IN遇到B表id含NULL时直接返回空结果集，这是SQL三值逻辑导致的确定性陷阱，不是bug。
-
WHERE a.id NOT IN (1, 2, NULL)→ 整个条件恒为UNKNOWN，不满足TRUE，所以没数据返回 -
LEFT JOIN ... WHERE b.id IS NULL完全不受B表是否含NULL影响，逻辑稳定 - 若B表主键或关联字段声明为
NOT NULL，NOT IN才勉强可用，但习惯性用LEFT JOIN更安全
ON条件写错会导致WHERE IS NULL失效
把本该写在WHERE里的过滤条件错放进了ON子句，会让LEFT JOIN“假装”B表有匹配，从而让WHERE b.id IS NULL漏掉本该抓到的数据。
例如想查“A表中状态为active但B表无对应记录的用户”：
SELECT a.* FROM users a LEFT JOIN orders b ON a.id = b.user_id AND b.status = 'paid'
这里b.status = 'paid'在ON里，会导致即使B表有同一用户的其他status订单，只要没有'paid'的，b.id仍为NULL——但你要的其实是“B表压根没这个user_id”，不是“B表没这个user_id的paid订单”。正确做法是：
SELECT a.* FROM users a LEFT JOIN orders b ON a.id = b.user_id WHERE b.id IS NULL AND a.status = 'active'
性能和索引注意事项
LEFT JOIN ... WHERE b.id IS NULL本质是嵌套循环+空值判断，对大表要警惕全表扫描。
- B表的关联字段（如
user_id）必须有索引，否则JOIN过程极慢 - 如果A表也很大，且只需少量字段，先用
WHERE缩小A范围再JOIN，别在JOIN后才过滤 - 某些旧版MySQL在
IS NULL上无法利用索引最左前缀，确认执行计划里type不是ALL
真正容易被忽略的是：当B表关联字段允许NULL且数量不少时，数据库可能放弃使用该字段索引——得看统计信息是否过期，必要时ANALYZE TABLE。
