RIGHT JOIN 有存在价值但场景有限，本质是以右表为基准返回其全部行及左表匹配行；多数情况可用LEFT JOIN替换，因其更符合从左到右阅读习惯、降低出错率且执行计划无性能差异。
RIGHT JOIN 有存在价值，但使用场景非常有限，多数时候可以被 LEFT JOIN 替换，关键在于理解它在逻辑表达和可读性上的特殊作用。
RIGHT JOIN 的本质是“以右表为基准”
RIGHT JOIN 返回右表所有行，以及左表中匹配的行；不匹配时左表字段为 NULL。这和 LEFT JOIN 刚好镜像——只是把左右表位置调换了。
例如：
- SELECT * FROM A RIGHT JOIN B ON A.id = B.a_id 等价于 SELECT * FROM B LEFT JOIN A ON B.a_id = A.id
- 执行结果完全一致，但语义重心从“B 补充 A 的信息”变成了“A 作为 B 的补充数据”
真正需要 RIGHT JOIN 的典型场景
当 SQL 语句已固定左表（比如主查询表、CTE 或子查询结果），又必须保留右侧某个维度表的全部记录时，RIGHT JOIN 能避免重构整个 FROM 子句。
- 多层嵌套查询中，右侧是预定义的维度表（如地区字典、状态码表），且不能/不便调整顺序
- 维护遗留 SQL 时，改动 FROM 顺序可能影响别名引用或 WHERE 条件，用 RIGHT JOIN 更稳妥
- 某些 BI 工具生成的 SQL 默认以某张表开头，后续关联需强制保右表全量，RIGHT JOIN 最直接
为什么大多数情况建议用 LEFT JOIN 替代
LEFT JOIN 更符合阅读习惯：人类通常从左到右理解“主表 → 关联表”，而 RIGHT JOIN 容易让人下意识忽略右表才是驱动表。
- 团队协作中，RIGHT JOIN 出错率更高——有人会误以为左表是主表，导致 NULL 值处理逻辑出错
- SQL 格式化工具和 Linter（如 SQLFluff）常默认警告或禁止 RIGHT JOIN
- 执行计划上无性能差异，优化器会自动重排，所以没必要为“看起来更顺”牺牲可维护性
一个不该用 RIGHT JOIN 的常见误解
有人认为“想查右表全量就必须用 RIGHT JOIN”，这是错的。只要把右表写在 LEFT JOIN 的左边即可：
- ❌ SELECT u.name, o.amount FROM users u RIGHT JOIN orders o ON u.id = o.user_id
- ✅ SELECT u.name, o.amount FROM orders o LEFT JOIN users u ON o.user_id = u.id
后者语义清晰、无需反转思维，还保持了“orders 是主数据源”的业务直觉。
