left join 应用于需保留主表全部数据且关联从表数据可为空的场景，如查所有学生及选课信息；若只需匹配数据则应用 inner join，且 on 条件不可误写入 where，多表连接需注意左结合性、别名清晰及索引优化。
LEFT JOIN 什么时候该用，什么时候不该用
当你要查“主表全部数据 + 可能存在的从表数据”时，LEFT JOIN 是唯一合理选择。比如查所有学生（不管有没有选课）、所有订单（不管有没有物流单号）、所有部门（不管有没有员工）。反过来，如果业务只要“有匹配才返回”，比如“查已发货的订单和对应物流信息”，就该用 INNER JOIN —— 强行用 LEFT JOIN 再加 WHERE logistics_id IS NOT NULL 过滤，不仅语义不清，还可能让优化器放弃使用索引。
ON 条件写错会导致 NULL 填充失效
LEFT JOIN 的保留逻辑只作用于 ON 子句里的条件；一旦把本该写在 ON 里的关联条件挪到 WHERE 里，就等价于 INNER JOIN。常见错误：
- 错误写法：
SELECT * FROM students s LEFT JOIN courses c ON s.id = c.student_id WHERE c.course_name LIKE '%数学%'→ 赵六（没选课）被过滤掉，因为c.course_name是NULL，不满足LIKE - 正确写法：把过滤下推到
ON：SELECT * FROM students s LEFT JOIN courses c ON s.id = c.student_id AND c.course_name LIKE '%数学%'→ 赵六还在结果里，只是课程字段为NULL
多表 LEFT JOIN 的顺序和别名必须清晰
三张表以上连查时，LEFT JOIN 是左结合的，即 A LEFT JOIN B LEFT JOIN C 等价于 (A LEFT JOIN B) LEFT JOIN C。这意味着：
- 第一张表（最左边）的数据一定全量保留
- B 表中没匹配的行，B 字段为
NULL；但 C 表是否保留，取决于它和“前一步结果”的关联，不是直接和 A 关联 - 务必给每张表起明确别名，避免字段歧义，例如：
SELECT s.name, c.course_name, l.tracking_no FROM students s LEFT JOIN courses c ON s.id = c.student_id LEFT JOIN logistics l ON c.id = l.course_id
性能陷阱：LEFT JOIN 后加 WHERE 条件可能让索引失效
MySQL 在执行 LEFT JOIN 时，会先完成连接再应用 WHERE。如果 WHERE 中包含右表字段的非 IS NULL 条件（如 c.status = 'active'），优化器大概率会放弃对右表使用索引，转而走全表扫描。更隐蔽的问题是：
- 右表没有为
ON字段建索引 → 连接过程变慢 - 右表数据量远大于左表 →
LEFT JOIN结果集膨胀，内存/临时表压力陡增 - 用
SELECT *拉取大量无用字段 → 网络和序列化开销翻倍
真正容易被忽略的是：LEFT JOIN 的“保留左表全部行”这个特性，在复杂嵌套或子查询里会被悄悄破坏——比如外层加了 GROUP BY 或 HAVING，又没注意聚合字段是否覆盖了左表主键，结果看似用了 LEFT JOIN，实则丢掉了本该保留的空匹配行。
