LEFT JOIN 与 RIGHT JOIN 的本质区别
LEFT JOIN 返回左表全部记录，右表只补匹配行（不匹配则为
NULL）；RIGHT JOIN 则反过来：右表全量保留，左表只填匹配项。二者逻辑完全对称，**差异仅在于主表（驱动表）是谁**——没有谁更“高级”，只有谁该被完整保留。
常见错误现象：
• 写了
RIGHT JOIN却发现结果和预期不符，其实是把业务上“要查所有用户”的需求，错配成了以订单表为主表；
• 把
LEFT JOIN A ON ...改成
RIGHT JOIN A ON ...后结果全乱，是因为没同步调整表顺序（
FROM t1 RIGHT JOIN t2≡
FROM t2 LEFT JOIN t1）。 LEFT JOIN 的主表是
FROM后第一个表（左表） RIGHT JOIN 的主表是
JOIN后那个表（右表） MySQL 不支持
FULL JOIN，但可用
LEFT JOIN ... UNION RIGHT JOIN ...模拟（注意去重）
什么时候必须用 RIGHT JOIN？
绝大多数场景下，
RIGHT JOIN都可被等价改写为
LEFT JOIN（只需调换两表顺序）。真正需要它的场景极少，典型如： 维护遗留 SQL，原语句结构固定且表别名嵌套深，强行改
FROM顺序易出错 右表是权威数据源（如配置表、字典表、库存台账），业务逻辑明确要求“以它为准”——例如查所有
inventory_sku记录，不管对应商品是否还在
products表中 某些 ETL 脚本中，右表是上游推送的增量快照，需确保每条快照都参与比对，哪怕左表暂无对应主键
实操建议：新写 SQL 时，**优先用
LEFT JOIN，把需要保全的表放在
FROM后**。这是团队协作中最不易误解的写法。
INNER JOIN 和 LEFT/RIGHT JOIN 混用的坑
最容易被忽略的是
WHERE子句对
LEFT JOIN结果的“悄悄过滤”——一旦在
WHERE中写了右表字段的非空条件，就事实退化为
INNER JOIN。
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
这句实际只返回“已付款的用户”，
users表里没下单或下单未付款的用户全被过滤掉了。正确写法应把条件移到
ON子句：
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
ON是连接时的筛选，决定哪些右表行能连上来
WHERE是连接后的筛选，会把整行（含左表）干掉
RIGHT JOIN同理，
WHERE中左表字段条件也可能意外丢数据
性能与可读性的真实权衡
LEFT/RIGHT JOIN 在执行计划上通常无性能差异，优化器会自动重排驱动表。但可读性上，
LEFT JOIN显式体现“我要保全谁”，而
RIGHT JOIN容易让读者多绕半秒去确认主表。
真实项目中见过的反模式：
用RIGHT JOIN实现“取右表独有数据”，其实应直接用
LEFT JOIN ... WHERE left_col IS NULL嵌套多层
RIGHT JOIN，导致阅读时需反复翻看
FROM和每个
JOIN的顺序 在视图定义里用
RIGHT JOIN，下游应用误以为右表是主表，导致 JOIN 链路错乱
最值得坚持的习惯：把业务语义强的表（如用户、商品、订单）放在
FROM，用
LEFT JOIN接扩展信息（地址、标签、日志），其他情况先问一句——“这个
RIGHT JOIN真的不可替代吗？”
