MySQL中的
RIGHT JOIN，说白了，就是以右侧的表为“主”，无论左侧表有没有匹配的记录，右侧表的所有记录都会被包含在结果集中。如果左侧表没有匹配项，那么左侧表的列会以
NULL值填充。这在你想确保右边的数据完整呈现，同时关联上左边的数据时，特别有用。
解决方案
使用
RIGHT JOIN的语法其实非常直观，它允许你从两个或多个表中根据某个条件关联数据，但始终保证右侧表的所有行都被返回。
基本的语法结构是这样的：
SELECT
列名1, 列名2, ...
FROM
左表名
RIGHT JOIN
右表名
ON
关联条件;这里，
左表名是你在
FROM子句中首先指定的表，而
右表名则是在
RIGHT JOIN关键字之后指定的表。
ON 关联条件定义了两个表之间如何匹配行的逻辑，通常是基于它们共同的列。
举个例子，假设我们有两个表：
departments（部门表）和
employees（员工表）。
departments表： | department_id | department_name | | :------------ | :-------------- | | 101 | Sales | | 102 | Marketing | | 103 | Engineering | | 104 | HR |
employees表： | employee_id | employee_name | department_id | | :---------- | :------------ | :------------ | | 1 | Alice | 101 | | 2 | Bob | 102 | | 3 | Charlie | 101 | | 4 | David | NULL |
现在，如果我想列出所有部门，以及每个部门对应的员工信息，即使有些部门目前没有员工，我也想看到这些部门。这时候，
departments就是我的“右表”，因为它是我要保证完整性的那部分数据。
SELECT
d.department_name,
e.employee_name
FROM
employees AS e
RIGHT JOIN
departments AS d ON e.department_id = d.department_id;执行这段SQL后，你会得到类似这样的结果：
| department_name | employee_name |
|---|---|
| Sales | Alice |
| Sales | Charlie |
| Marketing | Bob |
| Engineering | NULL |
| HR | NULL |
你看，
Engineering和
HR部门即使没有员工，也依然出现在了结果中，它们的
employee_name列显示为
NULL。这就是
RIGHT JOIN的典型行为。我个人觉得，当你需要从一个核心数据集（也就是这里的右表）出发，去“拉取”相关联的附加信息时，
RIGHT JOIN就显得非常自然了。
RIGHT JOIN 和 LEFT JOIN 有什么区别？
这是一个很多人初学SQL时都会纠结的问题。其实，
RIGHT JOIN和
LEFT JOIN在功能上是完全对称的，它们主要的区别在于哪个表被视为“主”表，或者说，哪个表的记录是保证会出现在结果集中的。
LEFT JOIN（左连接）会返回左侧表的所有行，以及右侧表中匹配的行。如果右侧表没有匹配项，则右侧表的列会显示为
NULL。
而我们前面讨论的
RIGHT JOIN（右连接），则会返回右侧表的所有行，以及左侧表中匹配的行。如果左侧表没有匹配项，则左侧表的列会显示为
NULL。
说白了，你可以把任何一个
RIGHT JOIN语句，通过简单地调换
FROM和
RIGHT JOIN后面的表名，然后把
RIGHT JOIN改成
LEFT JOIN，来得到相同的结果。
比如我们刚才的例子：
SELECT
d.department_name,
e.employee_name
FROM
employees AS e
RIGHT JOIN
departments AS d ON e.department_id = d.department_id;它可以被等效地改写成一个
LEFT JOIN：
SELECT
d.department_name,
e.employee_name
FROM
departments AS d
LEFT JOIN
employees AS e ON d.department_id = e.department_id;这两个查询会产生完全相同的结果集。在我看来，大多数开发者，包括我自己，可能更习惯使用
LEFT JOIN，因为我们从左到右阅读代码的习惯，使得
FROM table_A LEFT JOIN table_B这种结构读起来更顺畅，感觉上是“以A为基础去关联B”。但这纯粹是个人习惯和代码风格的问题，从数据库执行效率和最终结果来看，它们是等价的。选择哪个，更多是看哪种写法能让你的SQL意图表达得更清晰，尤其是在复杂的查询中。
什么时候应该使用 RIGHT JOIN？
虽然
RIGHT JOIN可以被
LEFT JOIN加表顺序调换来替代，但它依然有其存在的价值和适用的场景。我个人觉得，使用
RIGHT JOIN通常是为了强调或优先展示右侧表的数据完整性。
具体来说，以下几种情况可能会让你考虑使用
RIGHT JOIN：
当你的查询重心在右侧表时： 你想确保右侧表的所有记录都显示出来，即使它们在左侧表中没有对应的匹配项。例如，你有一个产品分类表（右表）和一个产品表（左表），你想列出所有分类，包括那些目前还没有任何产品的分类。
-- 假设 products 表有 category_id 字段，categories 表有 id 字段
SELECT
c.category_name,
p.product_name
FROM
products AS p
RIGHT JOIN
categories AS c ON p.category_id = c.id;这个查询会确保所有分类都被列出。
避免复杂的子查询或WHERE条件： 有时候，为了找到“右表有，左表没有”的记录，你可能会写一个
LEFT JOIN然后加
WHERE 左表.id IS NULL的条件。但如果你的初始设计就让右表是你想重点关注的，
RIGHT JOIN可以更直接地表达这种意图。
遗留系统或特定编码风格： 在一些老的系统或者团队有特定编码规范的情况下，
RIGHT JOIN可能被广泛使用。在这种情况下，为了保持代码风格的一致性，继续使用
RIGHT JOIN也是合理的。
数据审计或完整性检查： 比如，你有一个“标准数据”表（右表）和一个“实际录入数据”表（左表），你想检查标准数据中哪些项没有被实际录入，或者实际录入的数据与标准数据有哪些差异。使用
RIGHT JOIN可以很方便地列出所有标准数据，并指出哪些项在实际录入数据中缺失。
我个人在写查询时，倾向于使用
LEFT JOIN，因为觉得它更符合从左到右的阅读习惯。但如果遇到一个场景，右边的表真的是核心，而且我希望我的查询意图能一目了然地表达出来——即“我就是要看右边这张表的全部数据”，那
RIGHT JOIN绝对是个简洁有力的选择。关键在于清晰地表达你的意图，而不是拘泥于形式。
RIGHT JOIN 性能如何？有哪些注意事项？
关于
RIGHT JOIN的性能，其实它和
LEFT JOIN在MySQL内部的优化器处理上，通常没有本质区别。数据库优化器足够智能，它会根据你的查询语句、表结构、索引情况以及数据量，来选择最高效的执行计划。所以，你不用担心
RIGHT JOIN天生就比
LEFT JOIN慢，或者反之。
但有一些通用的注意事项，无论你用哪种
JOIN，都应该留意：
索引是关键： 无论你使用
RIGHT JOIN还是其他任何类型的
JOIN，确保你的
ON子句中使用的列都建立了合适的索引。这是提高
JOIN性能最重要的一点。没有索引，数据库可能需要进行全表扫描，这在数据量大时会非常慢。比如，在
ON e.department_id = d.department_id中，
employees.department_id和
departments.department_id都应该有索引。
选择性： 关联条件的选择性也很重要。如果你的关联条件能迅速过滤掉大量不匹配的行，那么
JOIN的效率就会很高。
WHERE
子句的位置：
ON子句中的过滤： 如果你把过滤条件放在
ON子句中，它会在
JOIN操作执行时就进行过滤。对于
RIGHT JOIN来说，这意味着它会先尝试匹配，如果右表有而左表没有，左表部分仍然会是
NULL，但如果
ON条件中包含对左表的过滤，可能会导致某些原本能匹配的行因为左表不符合过滤条件而被排除。
WHERE子句中的过滤： 如果你把过滤条件放在
WHERE子句中，它会在
JOIN操作完成，生成完整的中间结果集之后再进行过滤。这可能会导致先生成一个很大的中间结果集，然后再进行过滤，效率可能不如在
ON子句中过滤。但对于
RIGHT JOIN来说，如果你在
WHERE子句中对左表的非
NULL列进行过滤，那么所有左表匹配失败（
NULL）的行都会被排除掉，这实际上就把
RIGHT JOIN的行为变成了
INNER JOIN，因为你排除了那些左侧没有匹配的右侧行。
举个例子，如果你想只看有员工的部门：
-- 这样写，会排除掉 Engineering 和 HR 部门，因为它们的 employee_name 是 NULL
SELECT
d.department_name,
e.employee_name
FROM
employees AS e
RIGHT JOIN
departments AS d ON e.department_id = d.department_id
WHERE
e.employee_name IS NOT NULL;这其实就等同于一个
INNER JOIN了。这其实是个很经典的陷阱，一不小心就会把外连接的效果“优化”没了。
表的大小： 尽管优化器很聪明，但在处理非常大的表时，
JOIN操作本身就是资源密集型的。尽量优化你的数据模型，避免不必要的
JOIN，或者考虑将大表拆分。
可读性： 我个人觉得，在团队协作中，代码的可读性有时候比微小的性能差异更重要。如果你的团队更习惯
LEFT JOIN，那么即使
RIGHT JOIN能达到同样效果，为了代码风格一致性和降低维护成本，使用
LEFT JOIN并调整表顺序可能更好。
总的来说，
RIGHT JOIN是一个完全合法的SQL操作符，理解它的行为和注意事项，能让你在编写复杂查询时多一个选择。关键是理解其背后的逻辑，并结合实际场景做出最合适的选择。
