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中的非等值条件（如
、<code>BETWEEN）支持有限，复杂条件建议先子查询或临时表处理 实际写 JOIN 时，最易被忽略的是条件位置和 NULL 处理——不是语法不会写，而是没意识到
WHERE一句就可能让 LEFT JOIN 失去“保留左表”的意义。
