LEFT JOIN + WHERE 右表主键 IS NULL 是查找左表有而右表无记录的最直接可靠方法，需用右表主键或NOT NULL字段判空，避免误用可空字段或写成= NULL。
LEFT JOIN 后用 WHERE IS NULL 找出左表有、右表无的记录
LEFT JOIN 本身不会直接标出“差异”，它只是把左表全量保留，右表匹配不上就填 NULL。真正识别差异靠的是后续过滤：用 WHERE 右表主键 IS NULL（或任一必非空字段）锁定那些左表存在但右表完全没匹配上的行。
常见错误是写成 WHERE 右表某字段 = NULL——这永远不成立，因为 NULL 不能用等号判断，必须用 IS NULL。
- 确保右表用于判断的字段在
ON条件中已正确关联（比如ON a.id = b.id），否则IS NULL没意义 - 优先选右表的主键或定义为
NOT NULL的字段做IS NULL判断，避免因业务字段本身允许NULL导致误判 - 如果右表有多个可能匹配行，而你只想确认“是否存在任意一行”，
LEFT JOIN+IS NULL仍可靠；但若需排除“部分匹配”，就得换思路（见下一条）
要找“左表有、右表无对应数据”的完整差异，得先去重再 JOIN
当右表存在一对多关系（比如订单表 vs 订单明细表），直接 LEFT JOIN 可能导致左表某行重复出现多次，干扰 IS NULL 判断逻辑——哪怕右表其实有数据，只要某次 JOIN 结果某字段为 NULL，就可能被误判为“缺失”。
这时候得先对右表按关联键聚合或去重：
- 用
SELECT DISTINCT 关联字段 FROM 右表生成临时右表视图，再与左表LEFT JOIN - 或用
GROUP BY 关联字段配合任意聚合函数（如MAX(1)）构造存在性标记 - 例如：找出所有在
users表中存在、但在orders表中从未下单的用户：SELECT u.*<br>FROM users u<br>LEFT JOIN (SELECT DISTINCT user_id FROM orders) o ON u.id = o.user_id<br>WHERE o.user_id IS NULL;
LEFT JOIN 找不出“右表有、左表无”的差异，那是 RIGHT JOIN 或反向 LEFT JOIN 的事
很多人以为 LEFT JOIN 能覆盖双向差异，其实它只保障左表完整性。想查右表独有数据，要么改用 RIGHT JOIN（可读性差，不推荐），要么把两表位置对调，继续用 LEFT JOIN：
- 写法上更清晰：把“被检查是否缺失”的表放左边，参考表放右边
- 例如查
orders中存在但users中不存在的user_id：SELECT o.user_id<br>FROM orders o<br>LEFT JOIN users u ON o.user_id = u.id<br>WHERE u.id IS NULL;
- 注意字段类型一致性：如果
o.user_id是字符串而u.id是整数，隐式转换可能失败或产生意外结果，务必显式CAST或提前清洗
性能敏感时，用 NOT EXISTS 替代 LEFT JOIN + IS NULL 更稳妥
当左表极大、右表有合适索引时，NOT EXISTS 子查询通常比 LEFT JOIN 更快，且语义更贴近“检查是否存在”：
-
NOT EXISTS在找到第一个匹配即停止，而LEFT JOIN会尝试连接所有匹配行（尤其右表一对多时） - 写法示例：
SELECT * FROM users u<br>WHERE NOT EXISTS (<br> SELECT 1 FROM orders o WHERE o.user_id = u.id<br>);
- 确保子查询中的关联字段（如
o.user_id）有索引，否则性能可能急剧下降 - 某些旧版 MySQL（5.6 之前）对
NOT EXISTS优化不佳，此时反而LEFT JOIN更稳——得看实际执行计划
实际用哪一种，取决于你手头的数据分布、索引情况和具体想回答的问题。最容易被忽略的是右表一对多导致的重复匹配问题，它会让看似正确的 LEFT JOIN 查询给出错误的“差异”结论。
