inner join只返回两表匹配行，易丢数据；left join保左表并用null标识缺失；right join应转为left join；多表join需谨慎，阿里规范禁超三表直接连接。
INNER JOIN 是默认交集，用错就丢数据
它只返回两张表都匹配上的行，比如 employees 和 departments 中 dept_id 能对得上的员工才出现。一旦某个员工没填部门 ID，或者部门表里删了那条记录，这人就彻底查不到。
- 别把它当“查全部员工+部门信息”的方案，那是
LEFT JOIN的活 - 字段名相同时（如两表都有
id），用USING(id)比ON a.id = b.id更简洁，还能避免重复列 - 如果连接字段没索引，
INNER JOIN会变慢——尤其是大表，MySQL 可能退化成嵌套循环全扫
LEFT JOIN 保左表，NULL 是信号不是 bug
当你想“列出所有员工，不管有没有部门”，就得用 LEFT JOIN。右表没匹配时，对应字段填 NULL，这不是报错，是设计行为。
-
WHERE dept_name IS NULL能快速找出没分配部门的员工，这是筛选“缺失关联”的标准写法 - 别在
ON条件里加右表的过滤（比如ON e.dept_id = d.id AND d.status = 'active'），否则会把左表本该保留的行意外过滤掉；真要筛右表，得挪到WHERE后面 - 阿里开发规范明确要求：被 JOIN 的字段类型必须一致，否则可能隐式转换导致索引失效
RIGHT JOIN 很少用，多数时候可改写为 LEFT JOIN
它和 LEFT JOIN 逻辑对称，但可读性差——谁记得哪边是“右”？实际项目里几乎没人主动写 RIGHT JOIN，因为调换表顺序 + 改用 LEFT JOIN 更直观。
- 下面两句等价：
SELECT * FROM employees RIGHT JOIN departments ON employees.dept_id = departments.id↔SELECT * FROM departments LEFT JOIN employees ON departments.id = employees.dept_id - 团队协作时，统一用
LEFT JOIN能减少理解成本，也方便 Code Review - MySQL 不支持
FULL OUTER JOIN，真要取并集，得用LEFT JOIN ... UNION RIGHT JOIN ...，但要注意去重开销
三张表以上 JOIN，先想能不能拆
连三张表（比如员工→部门→项目）语法上没问题：INNER JOIN departments ... INNER JOIN projects ...，但性能和可维护性会明显下降。
- 阿里规范强制规定：超过三张表禁止直接
JOIN，优先考虑是否能用子查询、临时表或应用层组装 - 每多一个 JOIN，MySQL 优化器选错执行计划的风险就上升——尤其当某张表没走索引时，复杂度可能从 O(N) 崩到 O(N×M×K)
- 如果必须连多表，确保每个
ON字段都有索引，且驱动表（最左的表）是结果集最小的那个
真正难的从来不是语法，而是判断“该不该连”——很多看似复杂的 JOIN，其实只是业务模型没理清，或者历史冗余字段没清理干净。
