MySQL 中 LEFT JOIN 后的 ON 与 WHERE：你真的用对了吗？

前言

在日常开发中，我们经常使用 JOIN 来关联多张表查询数据。其中，LEFT JOIN（左连接）因其保留左表所有记录的特性而被广泛使用。然而，一个看似简单的问题却常常引发争议和错误：

“在 LEFT JOIN 之后，应该用 ON 还是 WHERE 来添加过滤条件？”

这个问题的答案，不仅关系到查询结果的正确性，更直接影响数据的完整性和业务逻辑的准确性。今天，我们就来深入剖析 ON 和 WHERE 在 LEFT JOIN 中的作用机制，帮你彻底搞懂它们的区别与最佳实践。

---

一、从执行顺序说起：SQL 的逻辑处理阶段

在深入 ON 和 WHERE 之前，我们先回顾一下 SQL 查询的逻辑执行顺序（Logical Query Processing Order），这是理解两者区别的关键。

一个典型的 SELECT 查询语句的逻辑执行顺序如下：

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. HAVING
7. SELECT
8. DISTINCT
9. ORDER BY
10. LIMIT

请注意：ON 发生在 JOIN 阶段，而 WHERE 是在 JOIN 完成后对结果集进行过滤。

---

二、ON 与 WHERE 的本质区别

1. ON：连接条件（Join Condition）

• 作用时机：在连接（JOIN）操作执行时。
• 作用对象：决定右表中哪些行可以与左表的行进行匹配。
• 对 LEFT JOIN 的影响：
  • 如果右表没有满足 ON 条件的记录，左表的记录依然会被保留，右表对应的字段值为 NULL。
  • ON 条件不会过滤掉左表的记录。

2. WHERE：结果过滤条件（Filter Condition）

• 作用时机：在 JOIN 操作完成之后。
• 作用对象：对已经连接完成的整个结果集进行过滤。
• 对 LEFT JOIN 的影响：
  • 如果 WHERE 条件中包含了对右表字段的非空判断（如 WHERE b.status = 'active'），那么所有右表字段为 NULL 的记录（即左表有而右表无匹配的记录）将被过滤掉。
  • 这可能导致 LEFT JOIN 变成了事实上的 INNER JOIN，违背了使用 LEFT JOIN 的初衷。

---

三、实战案例：对比分析

我们通过一个具体的例子来直观感受两者的差异。

示例场景

假设我们有两个表：

• users（用户表）
• orders（订单表）

-- 用户表
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50)
);

INSERT INTO users VALUES (1, 'Alice'), (2, 'Bob'), (3, 'Charlie');

-- 订单表
CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT,
    amount DECIMAL(10,2),
    status VARCHAR(20)
);

INSERT INTO orders VALUES 
(101, 1, 100.00, 'completed'),
(102, 1, 200.00, 'pending'),
(103, 2, 150.00, 'completed');

我们的需求是：查询所有用户，并显示他们已完成的订单金额总和。如果没有订单或订单未完成，金额显示为 0 或 NULL。

---

❌ 错误写法：在 WHERE 中过滤右表字段

SELECT 
    u.id, 
    u.name, 
    SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed' OR o.status IS NULL
GROUP BY u.id, u.name;

问题分析：

• WHERE o.status = 'completed' 会过滤掉 status 不为 'completed' 的订单行。
• 对于用户 'Charlie'（id=3），他没有订单，所以 o.status 为 NULL。
• 虽然我们加了 OR o.status IS NULL，但这个条件是在 JOIN 之后才应用的。
• 实际上，WHERE o.status = 'completed' 已经将 pending 状态的订单（如 Alice 的 pending 订单）从结果集中排除，导致这些用户的部分数据丢失。
• 更严重的是，如果 WHERE 条件中没有 OR o.status IS NULL，那么 Charlie 这类没有订单的用户也会被过滤掉，导致 LEFT JOIN 失效。

---

✅ 正确写法：在 ON 中过滤右表字段

SELECT 
    u.id, 
    u.name, 
    SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'completed'
GROUP BY u.id, u.name;

执行过程：

1. LEFT JOIN 执行时，ON 条件 u.id = o.user_id AND o.status = 'completed' 决定了只有 status 为 'completed' 的订单才会与用户匹配。
2. 对于用户 'Alice'：匹配到 id=101 的订单（completed），id=102 的订单（pending）被 ON 条件排除，不参与连接。
3. 对于用户 'Bob'：匹配到 id=103 的订单（completed）。
4. 对于用户 'Charlie'：没有匹配的订单，因此右表字段为 NULL。
5. GROUP BY 和 SUM 对结果集进行聚合。

结果：

id	name	total_amount
1	Alice	100.00
2	Bob	150.00
3	Charlie	NULL

✅ 完美实现了需求：所有用户都保留，只统计已完成订单的金额。

---

四、何时使用 ON？何时使用 WHERE？

场景	推荐位置	原因
连接条件（如 u.id = o.user_id）	ON	这是 JOIN 的基础，必须放在 ON 中。
对右表的业务过滤（如 status = 'completed'）	ON	确保只连接符合条件的右表记录，同时保留左表所有记录。
对左表的过滤（如 u.active = 1）	WHERE	过滤左表记录应在 JOIN 之后进行。
对最终结果集的过滤（如 total_amount > 100）	WHERE 或 HAVING	WHERE 用于行级过滤，HAVING 用于聚合后的过滤。

核心原则：

• 想保留左表所有记录？ → 把对右表的过滤条件写在 ON 子句中。
• 想过滤最终结果？ → 使用 WHERE 子句，但注意不要因右表字段的非空判断而意外过滤掉左表的记录。

---

五、常见误区与避坑指南

误区 1：认为 WHERE 性能更好

有些人认为 WHERE 能提前过滤数据，性能更好。但实际上：

• ON 条件在连接时过滤，可以减少参与连接的数据量，通常更高效。
• WHERE 在连接后过滤，可能需要处理更大的中间结果集。

误区 2：混合使用导致逻辑混乱

-- ❌ 混乱写法，难以维护
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed' AND u.active = 1;

应拆分为：

-- ✅ 清晰写法
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'completed'
WHERE u.active = 1;

---

六、总结

对比项	ON	WHERE
执行阶段	连接前（决定如何连接）	连接后（过滤结果）
对左表影响	不影响（保留所有左表记录）	可能过滤掉左表记录
对右表影响	决定哪些右表记录参与连接	决定哪些连接后的行保留在结果中
推荐用途	连接条件 + 右表业务过滤	左表过滤 + 结果集过滤

一句话总结：
在 LEFT JOIN 中，对右表的过滤条件应尽量放在 ON 子句中，以确保左表的完整性；对左表或最终结果的过滤则使用 WHERE。

---

如需获取更多关于MySQL 高级查询、索引优化、执行计划分析、数据库架构设计等内容，请持续关注本专栏《MySQL 深度探索》系列文章。