inner join 返回两表匹配的交集行，适合“必须有配套数据”场景；left join 保留左表全量，右表缺失填null；full outer join 暴露双表断层，mysql需模拟；on控制连接逻辑，where控制连接后过滤。
INNER JOIN 只要匹配的行，不匹配的直接丢
它不是“默认连接”，而是最严格的交集操作：左表某行在右表找不到对应记录，整行就不出现在结果里。业务上适合“必须有配套数据”的场景，比如查“已下单用户的收货地址”，没下单的用户你根本不想看。
- 常见错误现象：
SELECT * FROM users INNER JOIN orders ON users.id = orders.user_id却发现用户数比预期少——很可能有些用户还没下过单 - 使用场景：订单详情页、权限校验（用户+角色表必须同时存在）、报表中只统计“已关联数据”
- 性能影响：通常最快，数据库能利用索引高效过滤；但若连接字段无索引，会退化为嵌套循环，慢得明显
- 参数差异：部分方言（如 MySQL）允许省略
INNER，写成JOIN，语义完全等价；但显式写INNER JOIN更利于团队协作和代码可读
LEFT JOIN 保左表全量，右表缺啥填 NULL
这是你做“主表兜底查询”最常用的武器。比如查所有学生 + 他们的成绩，哪怕某学生还没考试，也要出现在列表里，score 字段显示为 NULL 就对了。
- 常见错误现象：写了
LEFT JOIN，但 WHERE 条件里又写了WHERE scores.score > 60，结果把没成绩的学生全过滤掉了——WHERE是在 JOIN 后过滤，NULL > 60恒为 false - 使用场景：后台管理列表（用户+最后登录时间）、数据补全（商品+销量）、缺失分析（哪些客户没下过单）
- 空值处理要点：判断右表字段是否为空，要用
IS NULL或IS NOT NULL，不能用= NULL - 注意别写反：
FROM students LEFT JOIN scores是对的；如果写成FROM scores LEFT JOIN students，就变成“保成绩不保学生”，逻辑全乱
FULL OUTER JOIN 不常用，但跨系统对账时真救命
它真正的作用不是“看起来完整”，而是暴露两边的数据断层。比如把旧系统导出的用户表和新系统同步后的用户表做 FULL JOIN，就能一眼看出：哪些人在新系统里消失了，哪些是新增的脏数据。
- 兼容性坑：MySQL 原生不支持
FULL OUTER JOIN，得用LEFT JOIN+RIGHT JOIN+UNION模拟，写法啰嗦且易错 - 使用场景：ETL 数据核对、迁移前后一致性检查、双写日志比对
- 性能影响：因为要扫两表全量，数据量一大就卡；务必加好连接字段索引，否则可能直接 OOM
- 别当“保险兜底”滥用：想查“所有用户及订单”，用
FULL JOIN users/orders看似全面，实则会把“没用户信息的订单”也拉出来——这种脏数据通常该被清洗，而不是展示
ON 和 WHERE 的位置差一毫，结果差一半
很多人以为 ON 和 WHERE 都是过滤条件，只是写法不同。其实它们执行时机完全不同：ON 在连接过程中起作用，WHERE 在连接完成后再过滤整行。
- LEFT JOIN 下最典型陷阱：
FROM users LEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid'—— 这会把所有没订单的用户干掉，因为orders.status是NULL，不满足= 'paid' - 正确写法：把过滤条件挪进
ON子句：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'，这样没订单或订单非 paid 的用户仍保留，orders.*字段为 NULL - INNER JOIN 下两者效果常一致，但逻辑上仍有区别：ON 控制“怎么连”，WHERE 控制“连完留谁”，混用容易让后续维护者误判意图
实际写 JOIN 时，最难的往往不是语法，而是想清楚“我到底要保留谁、舍弃谁、用什么判断缺失”。一旦连接逻辑和业务语义对不上，后面加再多 COALESCE 或子查询都救不回来。
