必须用LEFT JOIN而非RIGHT JOIN时，是需保全FROM后首表全部数据，如查所有用户及订单；RIGHT JOIN仅在极少数场景（如维护旧脚本或强调右表为权威源）才不可替代。
LEFT JOIN 什么时候必须用，而不是 RIGHT JOIN
当你明确要“保全 FROM 后第一个表的全部数据”，就该用 LEFT JOIN。比如查所有用户及其订单：SELECT * FROM users LEFT JOIN orders ON users.id = orders.user_id——users 是业务主体，不能丢人，哪怕某人没下单也要出现在结果里。
常见错误是把 RIGHT JOIN 当成“右表优先”的快捷写法，结果写成 FROM users RIGHT JOIN orders，本意是想保留所有订单，却让 users 表成了被驱动方，逻辑反了。真正该保留订单时，正确做法是把订单表挪到 FROM 后：FROM orders LEFT JOIN users，语义清晰、可读性强。
- 新写 SQL 时，一律把要保全的表放在
FROM后，然后用LEFT JOIN -
RIGHT JOIN在绝大多数团队里被视为“可读性风险”，不是语法错，是协作成本高 - 只有极少数场景才绕不开
RIGHT JOIN：比如维护一段嵌套多层JOIN的旧脚本，改FROM顺序可能牵连别名和子查询，风险大于收益
RIGHT JOIN 的真实适用场景不是“右表重要”，而是“右表是权威源”
RIGHT JOIN 的存在意义，不在于它多强大，而在于它能直白表达一种业务约束：右表的数据是“不可质疑的事实”，左表只是补充信息。例如库存台账表 inventory 和商品主表 products，如果要查“所有在库 SKU 及其商品名称”，就必须以 inventory 为准——哪怕某些 sku_id 在 products 中已下线或录入错误。
这时写 FROM products RIGHT JOIN inventory ON products.sku = inventory.sku，比调换顺序写成 FROM inventory LEFT JOIN products 更贴近原始需求描述：“我要所有 inventory 记录”。但注意：这种写法只在业务文档/注释里明确标注“以 inventory 为准”时才有价值，否则纯属增加理解负担。
- 权威源通常具备：不可删、不可改、上游系统强约束、审计要求留痕等特点
- 如果只是“右表数据多”，不构成用
RIGHT JOIN的理由；数据量不影响连接语义 - MySQL 不支持
FULL OUTER JOIN，但可用LEFT JOIN ... UNION ALL SELECT ... RIGHT JOIN ...模拟，此时RIGHT JOIN是语法必需，无法替代
LEFT JOIN 的 WHERE 条件一加，就悄悄变成 INNER JOIN
这是最隐蔽也最常踩的坑：LEFT JOIN 本身保留左表全部行，但如果在 WHERE 子句里写了右表字段的非空判断，比如 WHERE orders.status = 'paid'，数据库会先做连接，再过滤——那些原本右表为 NULL 的行（如未下单用户）直接被踢掉，效果等同于 INNER JOIN。
正确做法是把这类条件挪到 ON 子句里：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'。这样，未下单用户仍保留，而已下单但状态非 paid 的订单也不会混进来。
-
ON控制“怎么连”，WHERE控制“连完怎么筛” - 对右表字段做筛选，99% 的情况应放在
ON里，除非你真想丢掉左表无匹配的行 - 用
EXPLAIN查执行计划时，若发现type从ALL变成ref或eq_ref，说明优化器可能因WHERE过滤提前剪枝，改变了语义
性能上 LEFT JOIN 和 RIGHT JOIN 没区别，但索引位置很关键
MySQL 优化器对 LEFT JOIN 和 RIGHT JOIN 的处理完全对称，执行计划不会因写法不同而变慢。真正影响性能的是连接字段是否有索引、类型是否一致、以及哪张表更小（作为驱动表）。
比如 users 表百万行，orders 表千万行，用 FROM users LEFT JOIN orders 时，MySQL 默认选 users 为驱动表，逐行去 orders 找匹配——这就要求 orders.user_id 必须有索引。反过来，如果写成 FROM orders LEFT JOIN users，驱动表变成 orders，哪怕 users.id 有索引，也救不了全表扫描 orders 的开销。
- 永远给
JOIN条件中被查找的字段建索引，通常是右表的外键字段 - 不要指望调换
LEFT/RIGHT能优化性能，真正起作用的是表顺序 + 索引 + 数据分布 - 用
STRAIGHT_JOIN强制驱动表顺序前，先确认EXPLAIN给出的默认选择确实不合理
实际写 SQL 时，RIGHT JOIN 几乎只出现在两种地方：遗留代码里没人敢动，或者 DBA 写的运维脚本里刻意强调数据源权威性。其余时候，把要保全的表放左边，老老实实用 LEFT JOIN，是最省心、最不易出错的选择。
