left join 保留左表全部行，右表无匹配则补 null；inner join 仅返回两表都能匹配的行。语义上前者强调“左表为主、右表可选”，后者强调“必须同时存在”。
LEFT JOIN 和 INNER JOIN 的本质区别在哪
区别不在语法或写法，而在语义：INNER JOIN 表示“必须同时存在”，LEFT JOIN 表示“左表为主，右表可选”。INNER JOIN 结果行数 ≤ 左表行数；LEFT JOIN 结果行数 ≡ 左表行数（哪怕右表完全没匹配）。
常见错误现象：
- 报表中用户总数比
users表本身少 → 实际是INNER JOIN把没订单的用户过滤掉了 -
COUNT(*)和COUNT(orders.id)差距极大 → 很可能混淆了连接类型和聚合逻辑 - 前端显示“该用户无数据”，但数据库确认该用户存在 →
WHERE误写在LEFT JOIN后，把 NULL 行干掉了
什么时候必须用 LEFT JOIN
只要需求里出现“所有 X”“全部 X”“包含未……的 X”，且 X 是左表主语，就必须用 LEFT JOIN。
典型场景：
- 查所有用户及其订单数（含从未下单的用户）→
users为左表 - 导出全部商品及对应分类名称（含未绑定分类的商品）→
products为左表 - 列出所有员工及其最新考勤记录（含当天缺勤/未打卡者）→
employees为左表
关键陷阱：右表过滤条件不能写在 WHERE，否则 LEFT JOIN 就失效。例如想查“所有用户 + 其已支付订单”，下面写法是错的：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
正确写法是把条件移到 ON 子句：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
INNER JOIN 适合什么场景
INNER JOIN 不是“默认更安全”的写法，它是明确要丢弃孤立行的设计选择。
适用情况：
- 核对一致性：比如查“哪些订单关联了真实存在的用户” →
INNER JOIN users ON orders.user_id = users.id - 构建中间宽表：仅需有效关联字段，脏数据本就不该进下游
- ETL 清洗：明确剔除
user_id为空或无效的订单
注意：INNER JOIN 对 NULL 不匹配 —— 如果连接字段本身含 NULL（如 orders.user_id IS NULL），那这行永远进不了结果，这点常被忽略。
ON 和 WHERE 在 LEFT JOIN 里为什么不能互换
ON 决定“如何连接”，WHERE 决定“要哪些行”。这是最容易踩坑的地方。
对于 LEFT JOIN：
-
ON中的非关联条件（如o.status = 'paid'）只影响右表匹配行为，不丢左表数据 -
WHERE中的条件是对整行生效，一旦右表字段为NULL，NULL = 'paid'判定为 false，整行被过滤
简单记：LEFT JOIN 想保留左表全量，所有右表筛选逻辑必须塞进 ON，而不是 WHERE。
复杂点在于，业务需求经常隐含“既要全量左表，又要限定右表状态”，这时候 ON 条件的组合顺序、NULL 处理、以及是否需要 COALESCE 或 CASE，都得跟着一起调。别图省事堆在 WHERE 里——那不是简化，是埋雷。
