INNER JOIN仅返回两表匹配的记录，性能最优但会丢弃无关联数据；LEFT JOIN保留左表全部记录，右表无匹配则补NULL；MySQL不支持RIGHT/FULL OUTER JOIN，需用UNION模拟；ON与WHERE位置错误会导致JOIN语义改变。
INNER JOIN 只要匹配的数据
当你明确只需要两个表中都存在对应关系的记录时，用 INNER JOIN。它会自动过滤掉任一表中没有匹配项的行，结果集最小、性能通常最好。
常见错误是误以为 INNER JOIN 能“补全”缺失数据——它恰恰相反，会把没关联上的全丢掉。
- 订单表
orders和用户表users关联查下单用户信息：只关心“有订单且用户存在”的记录，就该用INNER JOIN - 如果
orders.user_id有脏数据（比如指向已删除用户的 ID），这些订单会被直接排除，不报错也不提醒 - 在大表关联时，
INNER JOIN更容易利用索引加速，尤其是连接字段上有索引的情况下
LEFT OUTER JOIN 保留左表全部记录
LEFT OUTER JOIN（常简写为 LEFT JOIN）的核心作用是：确保左表每一行都出现在结果里，右表没匹配上的字段填 NULL。
典型使用场景是“主表 + 可选附属信息”，比如查用户及其最近一笔订单：
SELECT u.id, u.name, o.order_no, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.created_at = ( SELECT MAX(created_at) FROM orders WHERE user_id = u.id );
- 注意：
ON条件里加了子查询限制“最近一笔”，这种写法在 MySQL 中可行，但性能差；更稳妥的是先聚合再 JOIN - 如果把过滤条件写在
WHERE里（如WHERE o.status = 'paid'），会把原本右表为 NULL 的行也过滤掉，等效于INNER JOIN -
LEFT JOIN结果行数 ≥ 左表行数，务必确认业务是否能接受NULL字段
RIGHT 和 FULL OUTER JOIN 在 MySQL 中不可用
MySQL 原生不支持 RIGHT JOIN 的语义等价写法（虽然语法允许，但优化器可能重写），更不支持 FULL OUTER JOIN。
想实现“两边都不丢”的效果，必须用 UNION 拼接两次 LEFT JOIN：
SELECT u.id, u.name, o.order_no FROM users u LEFT JOIN orders o ON u.id = o.user_id UNION ALL SELECT u.id, u.name, o.order_no FROM orders o LEFT JOIN users u ON u.id = o.user_id WHERE u.id IS NULL;
- 上面写法有重复风险（若某用户和某订单恰好都无匹配，会重复出现），实际要用
UNION去重，或加条件过滤 - 性能比原生
FULL OUTER JOIN差很多，大数据量下慎用 - 如果只是想补全右表缺失的左表数据，用
RIGHT JOIN不如直接调换表顺序写成LEFT JOIN，更清晰也更可控
ON 和 WHERE 的位置决定 JOIN 类型行为
同一个逻辑，ON 和 WHERE 放错位置，可能让 OUTER JOIN 变成 INNER JOIN。
-
ON是连接条件，控制“怎么匹配”，影响哪些行参与连接 -
WHERE是最终筛选，发生在连接完成之后，会把NULL行整个踢掉 - 例如：想查“所有用户 + 其已支付订单”，正确写法是把状态条件放在
ON：ON u.id = o.user_id AND o.status = 'paid'；若放WHERE，则没订单的用户就没了 - MySQL 对
ON中的非等值条件（如、BETWEEN）支持有限，复杂条件建议先子查询或临时表处理
实际写 JOIN 时，最易被忽略的是条件位置和 NULL 处理——不是语法不会写，而是没意识到 WHERE 一句就可能让 LEFT JOIN 失去“保留左表”的意义。