RIGHT JOIN 的本质是以右表为驱动表，保留其全部行并用左表匹配数据，不匹配则填 NULL；它与 LEFT JOIN 逻辑对称但主次颠倒，多数场景可被等价替换为 LEFT JOIN 以提升可读性与维护性。
RIGHT JOIN 的本质是“右表驱动”
RIGHT JOIN 不是“把右表拼到左表右边”，而是明确以右表为基准，左表只提供匹配项。如果左表没对应行，对应字段就填 NULL。很多人误以为它和 LEFT JOIN 只是左右互换，其实逻辑主次完全颠倒——右表每行都必须出现在结果里，哪怕左表空着。
RIGHT JOIN 写法和 NULL 值处理要同步考虑
写 RIGHT JOIN 时，右表字段永远非空（除非你自己设了 WHERE 过滤），但左表字段可能全为 NULL。常见错误是直接在 WHERE 里对左表字段加条件，比如 WHERE orders.status = 'shipped'，这会把右表中所有没匹配上订单的记录也过滤掉，实际效果等同于 INNER JOIN。
- 想保留右表全部数据，
WHERE条件只能作用于右表字段，或用AND放在ON子句里（如ON customers.id = orders.customer_id AND orders.status = 'shipped'） - 左表字段参与筛选时，必须显式允许
NULL，例如WHERE orders.status IS NULL OR orders.status = 'shipped' - 聚合时注意：
COUNT(orders.id)会跳过NULL，而COUNT(*)统计的是结果行数，两者语义不同
RIGHT JOIN 和 LEFT JOIN 可以互相转换，但可读性差异大
语法上，SELECT * FROM A RIGHT JOIN B ON A.x = B.x 等价于 SELECT * FROM B LEFT JOIN A ON B.x = A.x。但多数团队约定用 LEFT JOIN 表达“主表在左”，所以硬写 RIGHT JOIN 容易让同事多花半秒反应。除非右表确实是业务主实体（比如统计所有产品，不管有没有销量），否则优先调换表顺序改用 LEFT JOIN。
- MySQL 8.0+、PostgreSQL、SQL Server 都支持 RIGHT JOIN，但 SQLite 不支持（会报错
near "RIGHT": syntax error） - 某些 ORM（如 Django ORM）根本不生成 RIGHT JOIN，强行用可能触发底层报错或静默降级
- 执行计划里 RIGHT JOIN 通常会被优化器重写为 LEFT JOIN，实际性能无差别，但可读性和维护成本有差别
用 RIGHT JOIN 做“补全缺失关联”的典型场景
最稳妥的用途是：你有一张“基准维度表”，需要查出它所有记录，并附上事实表中能找到的关联数据，找不到就留空。比如查所有部门（departments），并带出每个部门当前有多少员工（employees），哪怕有些部门还没招人。
SELECT d.name, COUNT(e.id) AS emp_count FROM departments d RIGHT JOIN employees e ON d.id = e.dept_id GROUP BY d.id, d.name;
注意这里用了 RIGHT JOIN，但实际更常见且清晰的写法是调换顺序：FROM employees e RIGHT JOIN departments d ... → 改成 FROM departments d LEFT JOIN employees e ...。真正需要 RIGHT JOIN 的时刻，往往是 legacy SQL 搬迁或对接固定接口时无法改表序。
容易被忽略的是：RIGHT JOIN 的 ON 条件一旦写错（比如漏掉右表字段引用），可能导致笛卡尔积或意外过滤，而且问题不容易在小数据集上暴露。上线前务必用 EXPLAIN 看实际驱动表和行数预估。
