left join + where 右表主键 is null 是查找左表有而右表无记录的可靠方式；必须用右表主键或not null字段判空，避免误用可空字段导致错判，且需为右表关联字段建索引以保障性能。
LEFT JOIN + IS NULL 是唯一可靠方式
想找出左表有、右表没有的记录，不能只靠 LEFT JOIN 本身——它默认会把右表字段填成 NULL，但你得显式筛出来。关键在 WHERE 子句里加右表主键或非空字段的 IS NULL 判断，否则会漏掉或错判。
-
ON条件只控制连接逻辑，不过滤结果；WHERE才真正剔除行 - 必须选右表中「定义上不允许为
NULL」的字段（比如主键、带NOT NULL约束的列），用IS NULL才有意义 - 如果误用右表允许为
NULL的字段（如备注字段），可能把本该保留的记录也过滤掉
写法示例：找 orders 中没有对应 customer 记录的订单
假设 orders 表有 customer_id，customers 表主键是 id：
SELECT o.* FROM orders o LEFT JOIN customers c ON o.customer_id = c.id WHERE c.id IS NULL;
这里必须用 c.id IS NULL，而不是 o.customer_id IS NULL——后者查的是「订单本身就没填客户 ID」的记录，不是「客户 ID 存在但客户表里找不到」。
常见错误：WHERE 条件写错位置或字段
这些写法都会出问题：
- 把
IS NULL放到ON子句里：LEFT JOIN customers c ON o.customer_id = c.id AND c.id IS NULL—— 这会让LEFT JOIN变成无效连接，结果等价于CROSS JOIN加过滤，极慢且语义错误 - 用右表可空字段判断：
WHERE c.name IS NULL—— 如果客户表里真有name为NULL的合法记录，就会被误删 - 忘记加
WHERE，只写LEFT JOIN—— 结果包含所有左表记录，混着匹配成功和失败的行，没法区分
性能与索引提醒
这个查询实际执行时，数据库仍需扫描右表来确认是否匹配。如果右表很大，没索引会很慢：
- 确保
JOIN条件中的右表字段（如customers.id）有索引 - 某些旧版 MySQL 在
WHERE ... IS NULL场景下可能无法利用索引，建议用EXPLAIN看执行计划 - 如果只是校验数据完整性，偶尔跑一次没问题；高频使用时，考虑加个物化视图或定期维护反向标记字段
最易忽略的一点：很多人以为 LEFT JOIN 后右表字段为 NULL 就代表“不存在”，却没验证那个 NULL 是连接失败导致的，还是右表本身就存了 NULL。务必用主键或非空约束字段做判断。
