left join 以左表为主表，right join 以右表为主表，本质是主表选择不同；二者逻辑对称，可相互转换；实际开发中因可读性差、反直觉而极少使用。
LEFT JOIN 和 RIGHT JOIN 的本质区别在哪？
本质就一条：谁是主表（保留全部记录的表），谁是从表（只填匹配项，不匹配就 NULL）。LEFT JOIN 以 FROM 后第一个表（左表）为主表；RIGHT JOIN 则以 JOIN 后那个表（右表）为主表。其他逻辑完全对称——不是“功能不同”，而是“主次关系翻转”。
- 写
SELECT * FROM A LEFT JOIN B ON A.id = B.a_id→ A 全出，B 匹配不上就 NULL - 写
SELECT * FROM A RIGHT JOIN B ON A.id = B.a_id→ B 全出，A 匹配不上就 NULL - 二者结果集可以完全等价：把表顺序调换 + 改用 LEFT JOIN 就能替代 RIGHT JOIN（例如
SELECT * FROM B LEFT JOIN A ON A.id = B.a_id）
实际开发中为什么几乎不用 RIGHT JOIN？
不是它不能用，而是它容易引发阅读和维护陷阱。人脑读 SQL 习惯从左到右，FROM A RIGHT JOIN B 看着像“先查 A 再右连 B”，但实际语义却是“以 B 为主”，反直觉。团队协作时，别人扫一眼容易误判主表意图。
- 绝大多数 LEFT JOIN 场景都能通过调整表顺序重写为 LEFT JOIN，更符合思维惯性
- MySQL 执行器对
LEFT JOIN和RIGHT JOIN的优化路径一致，性能无差异 - 部分 ORM（如 Django ORM、MyBatis Plus）默认只生成 LEFT JOIN，不支持显式 RIGHT JOIN 语法
- 代码审查时，遇到 RIGHT JOIN 往往会被要求重构 —— 不是错，是“不够清晰”
什么时候必须用 RIGHT JOIN？
几乎没有“必须”。但极少数场景下，若强行用 LEFT JOIN 会导致嵌套过深或别名混乱，可权衡使用。例如：已有复杂子查询作为左表，又想以右侧基础维表（如 dim_region）为基准补全所有区域信息，此时写 (subquery) RIGHT JOIN dim_region 可避免把子查询再包一层 FROM。
SELECT u.name, r.region_name FROM ( SELECT user_id, name FROM users WHERE status = 1 ) u RIGHT JOIN dim_region r ON u.region_id = r.id;
但更推荐写法仍是把维表放前面：
SELECT u.name, r.region_name FROM dim_region r LEFT JOIN users u ON u.region_id = r.id AND u.status = 1;
LEFT JOIN 中 ON 和 WHERE 的坑你踩过吗？
这是比 LEFT/RIGHT 选择更常翻车的地方：ON 是连接时过滤右表；WHERE 是连接后过滤整行。一旦在 LEFT JOIN 后加了 WHERE 右表字段 IS NOT NULL，就事实退化成 INNER JOIN。
- 错误写法（本想查所有部门 + 员工数，却漏掉无人部门）：
SELECT d.name, COUNT(e.id) FROM dept d LEFT JOIN emp e ON d.id = e.dept_id WHERE e.id IS NOT NULL GROUP BY d.name; - 正确写法（保留 NULL 部门）：
SELECT d.name, COUNT(e.id) FROM dept d LEFT JOIN emp e ON d.id = e.dept_id GROUP BY d.name; - 想筛“有员工的部门”？直接用
INNER JOIN，语义更干净
LEFT JOIN 的真正价值，在于“保左表完整性”；一旦 WHERE 拿右表字段做非 NULL 判断，这个保证就失效了——这点比纠结 LEFT 还是 RIGHT 重要得多。
