right join本质是右表驱动，以右表为基准逐行匹配左表，无匹配时左表字段填null；其逻辑与left join对称但方向相反，执行时右表为主干，非简单“硬塞数据”。
RIGHT JOIN 的本质是“右表驱动”
RIGHT JOIN 不是“把右表数据硬塞进结果”，而是以右表为基准，逐行匹配左表。如果左表没有对应记录，对应字段就填 NULL。这点和 LEFT JOIN 对称，但方向相反——很多人写错，是因为下意识按“先写左表、后写右表”的顺序去理解，其实执行时右表才是主干。
RIGHT JOIN 写法容易漏掉 ON 条件
没写 ON 或写成 WHERE 会导致笛卡尔积或过滤失效。常见错误是：用 WHERE 筛左表字段，结果把本该保留的右表空匹配行也删掉了。
-
RIGHT JOIN ... ON left.id = right.id✅ 正确：关联逻辑在连接阶段完成 -
RIGHT JOIN ... WHERE left.status = 'active'❌ 错误：WHERE在连接后过滤，会丢掉右表中左表无匹配且 status 不满足的行 - 真要过滤右表，用
WHERE right.category = 'A'是安全的；要过滤左表又保留右表全量，得用ON ... AND left.status = 'active'
MySQL 和 PostgreSQL 对 RIGHT JOIN 的处理一致，但可读性差
几乎所有主流 SQL 引擎都支持 RIGHT JOIN，语法行为没差异。但实际协作中，90% 的团队规范禁止使用它——因为人脑更习惯从左往右读，FROM a RIGHT JOIN b 看着像“b 依赖 a”，易引发误解。多数人会重写为 FROM b LEFT JOIN a，语义更直白。
示例：
SELECT b.name, a.order_id FROM orders a RIGHT JOIN customers b ON a.customer_id = b.id;
等价于：
SELECT b.name, a.order_id FROM customers b LEFT JOIN orders a ON a.customer_id = b.id;
当右表有重复关联键时，结果行数可能远超预期
RIGHT JOIN 不去重，右表每条记录都会参与匹配。如果右表某 id 出现 5 次，左表有 3 条匹配，那这 5 行里每行都会生成 3 条结果（共 15 行），不是“5 行 + NULL”。这是最容易被忽略的膨胀点。
- 确认右表关联字段是否唯一（比如用
SELECT id, COUNT(*) FROM right_table GROUP BY id HAVING COUNT(*) > 1） - 若业务只要“每个右表记录一条结果”，得提前聚合右表，或加
DISTINCT（但注意DISTINCT不能解决逻辑歧义） - 某些场景下，
LATERAL（PostgreSQL）或APPLY（SQL Server）比RIGHT JOIN更可控
