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，其实只是业务模型没理清，或者历史冗余字段没清理干净。
