left join + is null 是mysql中查找差集（a有b无）最直接可靠的方法，需确保on条件正确、关联字段有索引、判空用is null而非= null，并排除a表关联字段本身为null的情况。
LEFT JOIN + IS NULL 是找差集最直接的方式
MySQL 没有 FULL OUTER JOIN，也不支持 EXCEPT 语法，所以用 LEFT JOIN 配合 WHERE ... IS NULL 是识别「A 表有、B 表没有」这类差集数据的可靠方法。核心逻辑是：把 A 表作为主表左连接 B 表，再筛出 B 表关联字段为 NULL 的行。
常见错误是只写 LEFT JOIN 却漏掉 IS NULL 条件，结果返回的是全量左连接结果，不是差集。
- 必须在
ON子句中写清楚关联条件（比如ON a.id = b.id），不能挪到WHERE里，否则会退化成INNER JOIN - 判断空值一定要用
IS NULL，不能用= NULL（MySQL 中该表达式恒为 false） - 如果 B 表关联字段允许
NULL，且你只想排除“匹配失败”的情况，确保判空字段是JOIN中实际用于匹配的列（如b.user_id），而不是其他可能本来就是NULL的业务字段
ON 条件写错会导致差集结果失真
差集是否准确，高度依赖 ON 子句是否严格对应业务上的“存在即匹配”逻辑。例如，想查「订单表中有、但用户表中已删除（无对应记录）的用户 ID」，ON 必须基于主键或唯一标识字段；若误用非唯一字段（如用户名），可能因重复值导致多对一匹配，让本该被筛出的记录意外保留。
- 优先使用主键或带唯一约束的字段做关联，比如
ON orders.user_id = users.id - 避免用模糊字段（如
name、email）做ON条件，除非业务上明确允许同名不同人 - 如果关联字段类型不一致（如
VARCHARvsINT），MySQL 可能隐式转换并丢失精度，建议提前CAST或统一建表类型
性能关键：被驱动表的关联字段必须有索引
LEFT JOIN ... IS NULL 查询在数据量大时容易变慢，瓶颈通常出现在 B 表（右表）的关联字段上。因为 MySQL 需要对 A 表每行，在 B 表中快速确认“有没有匹配项”，这本质上是一次反向存在性检查。
- 确保 B 表的
ON字段上有索引（如INDEX (user_id)），否则会触发全表扫描 - 如果 B 表很大且只查差集，可考虑加
STRAIGHT_JOIN强制以 A 表为驱动表（需验证执行计划） - 不要在
WHERE中对 B 表字段加额外过滤（如AND b.status = 'active'），这会让IS NULL失效——正确做法是把条件移到ON子句中（ON a.id = b.id AND b.status = 'active'）
注意 NULL 值本身对差集语义的影响
如果 A 表的关联字段本身就含 NULL，这些行在 LEFT JOIN 后，B 表对应字段也一定是 NULL，会被误判为“B 表不存在”。这是差集查询中最容易被忽略的语义陷阱。
- 查差集前先确认 A 表关联字段是否允许
NULL；若允许，需额外排除：WHERE b.id IS NULL AND a.id IS NOT NULL - 如果业务上
NULL表示“未知”而非“不存在”，那它就不该参与差集计算，必须显式过滤 - 某些场景下，差集真正含义是「A 表中非空 ID 在 B 表中无对应记录」，此时
IS NOT NULL是必要前置条件
