先说几个关于 LEFT JOIN 的核心判断。很多人在实际写 SQL 时，明明用了 LEFT JOIN，结果却发现左表的行数莫名其妙减少了，或者右表的字段全是 NULL，又或者数据突然重复了。这背后其实就四个常见陷阱：左表行数本应不变，但 WHERE 条件写错会把它变成 INNER JOIN；右表多匹配会炸出行重复；NULL 值没处理好会让聚合计算直接翻车。下面逐一拆解说明。
LEFT JOIN 的核心行为：左表行数不变
LEFT JOIN 的底层逻辑再简单不过：左表有多少行，结果里就有多少行。哪怕右表没有匹配的记录，左表的每一行也都会保留下来，只不过右表对应的字段全部变成 NULL。这既不是“筛选”，也不是“补全”，而是“保留左表主干 + 尝试拼接右表”。关键点在于：只要没在 WHERE 里对右表字段做非空限制，就不会意外把左表行给过滤掉，从而确保 LEFT JOIN 保留左表全部数据。
WHERE 条件写错会让 LEFT JOIN 变成 INNER JOIN
这是最常见的翻车现场。很多人习惯把本该放在 ON 里的右表条件顺手写到 WHERE 里，比如 WHERE right_table.status = 'active'。一旦这个条件生效，那些右表没有匹配（即 status 为 NULL）的左表行就被直接干掉了——你的 LEFT JOIN 瞬间退化为 INNER JOIN，左表数据就丢失了，导致 SQL 查询结果与预期不符。
正确做法其实就一句话：
ON里放关联逻辑和右表的宽松过滤（比如ON a.id = b.a_id AND b.deleted = 0）WHERE里只写左表自身的约束（比如WHERE a.created_at > '2024-01-01'）
右表多匹配导致左表行重复，需提前预判
如果右表对左表的某一行有多个匹配记录（举个例子，一个订单对应三条物流跟踪记录），LEFT JOIN 会自然地生成多行结果。这不是 bug，这就是它该有的行为。但问题在于，很多场景下你其实只想取“最新的一条”或“任意一条”，这时候就得提前用子查询或窗口函数做“去重”预处理，避免 SQL 查询结果出现意料之外的数据膨胀。
比如取每个用户的最新登录记录，可以这样写：
SELECT u.*, l.last_login FROM users u LEFT JOIN ( SELECT user_id, MAX(created_at) AS last_login FROM logins GROUP BY user_id ) l ON u.id = l.user_id
NULL 值处理不当会影响后续计算
LEFT JOIN 之后，右表字段的值很可能就是 NULL。如果直接拿它们做 SUM()、COUNT() 或者字符串拼接，结果往往不是你想要的。比如 COUNT(b.id) 统计的是右表非空匹配的数量，而 COUNT(*) 才是左表的总行数——这两个结果完全不是一回事，容易导致聚合计算失误。
几个常用的应对手段：
- 用
COALESCE(b.amount, 0)替代裸字段参与数值运算，避免 NULL 导致结果偏差 - 用
b.name IS NOT NULL显式判断是否存在匹配记录 - 避免在
GROUP BY中混用左表和右表字段，除非你能百分百确认右表字段不会为NULL
实际写的时候，养成三个检查习惯：先盯住左表主键是否完整出现，再检查右表字段有没有意外变成 NULL，最后验证聚合或过滤有没有悄悄吃掉本该保留的行——这几个地方最容易踩坑，也最能看出一个人对 LEFT JOIN 的理解深度。掌握这些 LEFT JOIN 使用技巧，能有效避免数据丢失和重复问题，提升 SQL 查询的准确性。
