inner join只返回两表匹配的行，不匹配则整行消失；left join强制保留左表所有行，右表不匹配字段填null，但where中对右表过滤会破坏左表完整性。
INNER JOIN 只返回匹配行，不匹配的整行消失
它像一道严苛的筛选门：只有左表和右表在 ON 条件上完全对得上号，这一组合才被放行。任何一方缺位，整行就彻底不在结果里出现。
常见错误现象：SELECT * FROM users u INNER JOIN orders o ON u.id = o.user_id 查不到新注册但还没下单的用户——不是数据丢了，是 INNER JOIN 主动过滤掉了。
- 结果行数永远 ≤ 左表行数，也 ≤ 右表行数
- 右表字段绝不会因连接失败而出现
NULL（除非原始数据本身含NULL且参与了ON） - 优化器可自由交换驱动表顺序，性能通常更优
LEFT JOIN 强制保留左表所有行，右表不匹配就填 NULL
它以左表为绝对主体：左表每行都必须出现在结果中，右表只是“尽力配合”。配不上？右表字段直接上 NULL 占位。
使用场景举例：统计每个用户的订单数，包括零订单用户——COUNT(o.id) 配合 GROUP BY u.id，若用 INNER JOIN 就漏掉这部分人。
- 结果行数恒等于左表行数（除非
ON条件本身带额外限制） -
WHERE中对右表字段加条件会悄悄“阉割”左表完整性，比如WHERE o.status = 'paid'会把o.status IS NULL的行全干掉 - 真正想保留左表 + 只连已支付订单？条件必须写进
ON：ON u.id = o.user_id AND o.status = 'paid'
ON 和 WHERE 的位置决定 LEFT JOIN 是否“变味”
这是最常踩的坑。LEFT JOIN 后，右表字段的过滤条件放错地方，效果就从“保留左表”退化成“等效 INNER JOIN”。
错误写法：LEFT JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2025-01-01' —— 所有 o.created_at 为 NULL 的行（即无订单用户）被 WHERE 一并剔除。
- 要保留左表完整，同时只关联满足条件的右表记录：条件放进
ON - 要基于最终结果做全局过滤（比如只看某地区用户），且该字段来自左表：放
WHERE安全 - 右表字段参与过滤？99% 情况下应塞进
ON，否则语义就偏了
LEFT JOIN 的 NULL 是业务信号，不是脏数据
右表字段出现 NULL 不代表出错，而是明确告诉你：“左表这行，在右表里找不到对应记录”。这是判断缺失关联的关键依据。
例如查“没有订单的用户”：WHERE o.id IS NULL；查“有订单但未发货的用户”：WHERE o.status = 'paid' AND o.shipped_at IS NULL。
-
INNER JOIN结果里不会天然出现这种业务型NULL - 用
COALESCE(o.amount, 0)或IFNULL做展示层兜底可以，但别用它掩盖逻辑意图 - 索引有效性差异大：LEFT JOIN 的右表字段若参与
ON，索引仍可用；若被挪到WHERE，可能触发全表扫描
实际写 SQL 时，先问自己一句：这张查询的“主干”是谁？如果答案是左表，且它必须全员出场，那就别犹豫用 LEFT JOIN，再小心护住它的 ON 条件。
