SQL多表连接区别：INNER JOIN与LEFT JOIN的使用场景

INNER JOIN 只看匹配记录

在处理多表关联时，最直观的需求往往是“找出有订单的用户”。此时，INNER JOIN 是最直接的选择。它的核心规则非常严格：只有当左表（如 users）和右表（如 orders）的连接键（如 user_id）都存在且匹配时，结果集中才会包含该行。

假设我们有两张表：users 存储用户信息，orders 存储订单记录。如果用户 A 下了单，而用户 B 尚未下单，执行 INNER JOIN 后，用户 B 的记录会直接从结果中消失。

SELECT u.name, o.order_id
FROM users u
INNER JOIN orders o ON u.id = o.user_id;

为什么结果变少了？ 因为 INNER JOIN 本质上是取两表的交集。任何在右表中找不到对应 user_id 的左表记录，或者在左表中找不到对应用户的右表订单，都会被过滤掉。这种“少行”现象是符合预期的，它确保了返回的数据在两张表中都有确切的关联依据。

LEFT JOIN 保留左表

如果业务需求变为“列出所有用户，并显示他们是否有订单”，INNER JOIN 就不再适用，因为它会遗漏那些没有订单的用户。这时需要使用 LEFT JOIN（左外连接）。

LEFT JOIN 的规则是：保留左表的全部行。无论右表中是否有匹配的记录，左表的每一行都会出现在结果中。如果右表没有匹配项，对应的列将填充为 NULL。

SELECT u.name, o.order_id
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

在这个查询中，即使用户 B 没有下过单，他依然会出现在结果列表中，只是 order_id 字段显示为 NULL。这种机制常用于查找“缺失”的数据，例如找出“从未下过单的用户”，只需在后续加上 WHERE o.order_id IS NULL 即可。

匹配行与左表保留行的差异

上图清晰展示了两种连接方式的行保留差异：INNER JOIN 仅保留中间匹配的阴影部分，而 LEFT JOIN 则保留了左表的全部圆圈区域，未匹配部分以 NULL 占位。

ON 与 WHERE 的关键差异

在使用 LEFT JOIN 时，一个常见的错误是将针对右表的过滤条件放在 WHERE 子句中，而不是 ON 子句中。这会导致 LEFT JOIN “退化”为 INNER JOIN，从而失去保留左表未匹配行的意义。

场景对比： 我们想查看用户及其状态为“已完成”的订单，如果没有完成订单，用户仍需显示。

错误写法（条件在 WHERE）：

SELECT u.name, o.order_id, o.status
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed';

后果： WHERE 子句是在连接完成后对最终结果集进行过滤。对于没有订单的用户，o.status 为 NULL，而 NULL = 'completed' 的结果为假，因此这些用户会被剔除。最终结果只包含有“已完成”订单的用户，效果等同于 INNER JOIN。

正确写法（条件在 ON）：

SELECT u.name, o.order_id, o.status
FROM users u
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'completed';

原理： 将条件放在 ON 中，意味着在连接阶段就只匹配状态为“已完成”的订单。如果用户没有完成订单，连接依然成功（因为是 LEFT JOIN），只是右表字段全为 NULL，用户记录得以保留。

过滤条件放在 ON 或 WHERE 会改变结果

上图示意了过滤条件位置对结果的影响：放在 ON 中时，左表未匹配行依然保留；放在 WHERE 中时，这些行因不满足过滤条件而被移除。

按业务关系选择并排查

选择 JOIN 类型不仅取决于语法，更取决于业务逻辑中的表关系。在编写查询前，应先确认连接键的关系是“一对一”、“一对多”还是“多对多”。

检查重复键与行数放大： 如果右表（orders）中存在同一个 user_id 的多条记录，LEFT JOIN 或 INNER JOIN 都会导致左表（users）的行在结果中重复出现，造成结果集行数膨胀。例如，一个用户有 5 个订单，连接后该用户的信息会出现 5 次。

排查步骤：

1. 分别统计： 先单独查询左表和右表的主键数量，预估连接后的行数范围。
2. 查看未匹配行： 使用 LEFT JOIN 配合 WHERE right_table.key IS NULL 检查是否存在意外的数据缺失。
3. 核对 NULL： 检查结果集中右表字段为 NULL 的行，确认这些 NULL 是因为确实无匹配，还是因为过滤条件放置错误导致的。

在实际开发中，建议先使用 LEFT JOIN 进行探索性查询，因为它保留了更多信息，便于发现数据关联中的异常。确认逻辑无误后，若确定只需要匹配数据，再改为 INNER JOIN 以提升语义的清晰度。

参考资料

• PostgreSQL table expressions
• MySQL JOIN