LEFT JOIN 以左表为基准保留所有记录，右表无匹配则字段为 NULL；ON 控制关联逻辑，WHERE 过滤结果，误将右表条件放 WHERE 会过滤掉左表无匹配行；正确做法是将右表筛选条件移至 ON 子句。
LEFT JOIN 语法结构和核心逻辑
LEFT JOIN 的本质是：以左表为基准，不管右表有没有匹配行，左表所有记录都保留；右表只填入能匹配上的字段值，不匹配的字段全为 NULL。关键不是“怎么写”，而是“为什么左表数据不会丢”——因为 SQL 引擎在执行时先锁定左表全集，再逐行去右表找 ON 条件成立的记录。
-
ON子句决定匹配逻辑，必须写清楚关联字段（比如users.id = orders.user_id），不能用WHERE替代 - 如果在
WHERE中对右表字段加条件（如WHERE orders.status = 'paid'），会把原本NULL的行过滤掉，结果就不是真正意义的“左表全部” - 左表别名建议用短且明确的名称（如
u），右表同理（如o），避免后续字段引用歧义
常见错误：WHERE 条件误写导致左连接失效
这是最常踩的坑：本意要查所有用户及其订单，却写成：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'completed';
结果发现没下单的用户全没了——因为 WHERE o.status = 'completed' 把 o.status 为 NULL 的行直接筛掉了。
- 正确做法是把右表的筛选条件挪到
ON子句里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'completed' - 若需同时查“已完成订单”和“无订单用户”，这个
AND必须跟在ON后面，不能进WHERE - 多表左连接时，每个
LEFT JOIN后的ON都应独立控制该次连接的匹配范围
NULL 值处理与字段别名冲突
左连接后右表字段可能为 NULL，直接参与计算或排序容易出错。例如：
SELECT u.name, o.amount * 1.1 AS final_amount FROM users u LEFT JOIN orders o ON u.id = o.user_id;
一旦 o.amount 是 NULL，final_amount 就是 NULL，不是 0。
- 用
COALESCE(o.amount, 0)显式转默认值，比依赖应用层判断更可靠 - 如果左右表有同名字段（比如都叫
id），必须用别名区分：u.id AS user_id、o.id AS order_id -
SELECT *在左连接中极不推荐——字段顺序、重复名、NULL 扩散都难以控制
性能提示：LEFT JOIN 不等于全表扫描，但索引很关键
LEFT JOIN 不会强制扫右表全量，但若 ON 字段没索引，数据库大概率走嵌套循环（Nested Loop），右表每行左表记录都要翻一遍，数据量大时延迟飙升。
- 确保右表的关联字段（如
orders.user_id）建了索引 - 左表字段是否需要索引，取决于
WHERE或ORDER BY是否用到它，和LEFT JOIN本身无关 -
EXPLAIN查看执行计划时，重点看type是否为ref或eq_ref，而不是ALL
实际写的时候，最容易被忽略的是 ON 和 WHERE 的职责边界——一个管“连不连得上”，一个管“连上之后要不要”。连不上却被 WHERE 删掉，左连接就白写了。
