LEFT JOIN 保留左表所有行，未匹配右表字段填 NULL；INNER JOIN 仅返回两表匹配的行。关键区别在于是否丢弃左表未匹配行，业务语义决定选择：需主表完整用 LEFT JOIN，仅需交集用 INNER JOIN。
LEFT JOIN 和 INNER JOIN 的本质区别就一条：要不要丢掉左表里“没匹配上”的行
INNER JOIN 是个严格的筛子——两表连接字段必须同时存在且相等，才放行；哪怕左表有 100 条用户记录，右表只找到 60 条对应订单，结果就只有 60 行。LEFT JOIN 则是“保底操作”：左表每条都得出来，右表没匹配上的，order_id、amount 这些字段直接填 NULL。
- 判断依据很简单：结果里有没有右表字段为
NULL？有 → 很可能用了LEFT JOIN；全非空 → 大概率是INNER JOIN - 别被“LEFT”字面迷惑——它不关心右表是否完整，只保证左表不丢数据
- 如果误把
INNER JOIN写成LEFT JOIN，可能多出几十行NULL订单的用户，报表总数就虚高
什么时候必须用 LEFT JOIN：主表不能少，关联表可为空
典型场景就是“查所有用户 + 他们的订单信息”。业务逻辑要求：没下单的用户也得列出来（比如做用户活跃度分析），这时 LEFT JOIN 不是选项，是刚需。
- 常见错误：用
INNER JOIN查“所有客户及其最后一次登录时间”，结果漏掉新注册还没登录的用户 -
WHERE条件要小心：写在ON后是连接条件，写在WHERE后会把NULL行过滤掉，等于变相退化成INNER JOIN - 示例：
LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'—— 只关联已支付订单；若把status = 'paid'放WHERE，则没支付订单的用户也会被干掉
INNER JOIN 性能通常更好，但别为了快乱换 JOIN 类型
INNER JOIN 因为可以提前剪枝，数据库优化器更容易利用索引，执行计划通常更轻量。但如果你需要的是完整主表，硬换成 INNER JOIN 再补逻辑，反而更慢、更难维护。
- 左表 10 万行，右表没建索引 →
LEFT JOIN可能触发全表扫描+大量NULL填充，比INNER JOIN慢好几倍 - 别迷信“LEFT JOIN 更安全”，它只是保留了数据，但
NULL值可能让后续SUM()、COUNT()出错（比如COUNT(order_id)会忽略NULL，但COUNT(*)不会） - 真正影响性能的往往不是 JOIN 类型本身，而是连接字段有没有索引、数据倾斜程度、是否加了不当的
WHERE过滤
RIGHT JOIN 几乎不用，LEFT JOIN 调换表序就能替代
现实中几乎见不到 RIGHT JOIN 的合理使用场景。它和 LEFT JOIN 是镜像关系，但可读性差、容易绕晕人。所有 RIGHT JOIN 都能通过调换左右表位置 + 改用 LEFT JOIN 实现，且语义更直白。
- 错误写法：
orders RIGHT JOIN users ON users.id = orders.user_id - 推荐写法：
users LEFT JOIN orders ON users.id = orders.user_id—— 主表是谁，一眼就清楚 - 团队协作时，统一用
LEFT JOIN并固定“主表在前”，能减少理解成本和出错率
最常被忽略的点是：JOIN 类型选错，往往不是语法问题，而是对业务语义理解偏差。比如“统计有订单的用户数”该用 INNER JOIN，“统计全部用户及是否有订单”才用 LEFT JOIN。字段值是不是 NULL，背后是业务规则，不是 SQL 技巧。
