left join 与 right join 的本质区别在于主表不同：left join 以 from 后左表为主表，保留其全部记录；right join 以 join 后右表为主表，保留其全部记录；二者逻辑对称，可相互转换。
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 真的不可替代吗？”
