LEFT JOIN + WHERE 右表关联字段 IS NULL 是找出左表有、右表无记录的唯一可靠方式；必须用右表主键或NOT NULL字段判空，条件须置于WHERE而非ON，且需确保连接字段有索引。
LEFT JOIN + IS NULL 找出左表有、右表无的记录
MySQL 本身没有 FULL OUTER JOIN，但用 LEFT JOIN 配合 WHERE right_table.id IS NULL 是最直接的方式定位「左表独有」的数据。关键不是连接本身，而是过滤时机：必须在 WHERE 子句里判断右表字段是否为 NULL，而不是在 ON 条件里加额外限制，否则会把本该被筛掉的行提前排除。
-
ON只控制连接逻辑，WHERE才真正过滤结果集 - 如果右表关联字段允许
NULL（比如外键未设NOT NULL），要确认你筛的是「没匹配上」还是「匹配上了但值为空」 - 示例：查用户表
users中未在订单表orders中出现过的用户SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL;
用 LEFT JOIN 对比字段值差异（非空匹配但内容不同）
当两表已能通过主键/外键关联，但你想检查具体字段是否一致（比如同一用户的 email 在两张表中不一致），就不能只靠 IS NULL，得在 WHERE 中写字段比较条件。
- 必须确保连接条件正确，否则对比失去意义
- 注意
NULL值比较：直接用!=或无法匹配NULL，要用IS NULL单独判断，或用COALESCE统一兜底 - 示例：查
users和user_backup中同 ID 但phone不一致的记录SELECT u.id, u.phone AS current_phone, b.phone AS backup_phone FROM users u LEFT JOIN user_backup b ON u.id = b.id WHERE u.phone != b.phone OR (u.phone IS NULL AND b.phone IS NOT NULL) OR (u.phone IS NOT NULL AND b.phone IS NULL);
为什么不用 RIGHT JOIN？什么时候才需要它？
RIGHT JOIN 语义上等价于把左右表调换后的 LEFT JOIN，但可读性差，多数团队规范禁止使用。真正需要它的场景极少：
- 已有复杂嵌套查询，临时补一个右表关联，改写成本高（但建议仍重构成
LEFT JOIN） - 对接遗留 SQL 脚本，需最小改动保持行为一致
- 实际开发中，99% 的「找右表独有数据」需求，直接把右表写成左表、左表写成右表，用
LEFT JOIN更清晰
性能和索引容易被忽略的关键点
LEFT JOIN 查差异本身不慢，慢在没走索引。最容易踩的坑是连接字段没索引，或者用了函数导致索引失效。
- 连接字段（如
ON u.id = o.user_id）两端都必须有索引，且类型严格一致（比如都是INT UNSIGNED） - 如果用
ON u.email = LOWER(o.email)，o.email上的普通索引无效，得建函数索引（MySQL 8.0+）或提前标准化存储 - 大表对比前先
EXPLAIN看是否用了type=ref或eq_ref，避免全表扫描
实际执行时，如果差异数据量很大，SELECT * 会拖慢网络和内存，只选必要字段更稳妥。另外，LEFT JOIN 的结果集大小取决于左表，跟右表是否匹配无关——这点常被误认为“右表数据多就慢”，其实慢的是连接本身，不是右表行数。
