多表关联需明确业务目标、理清关系、选对连接方式，并精准使用ON和WHERE；常见错误包括ON条件写错、混淆JOIN类型、忽略NULL影响。
多表关联不是“把几张表连起来就行”，关键在明确业务目标、理清表间关系、选对连接方式，再用WHERE和ON精准过滤。写错ON条件、混淆INNER/LEFT结果、忽略NULL影响，是90%初学者踩坑的根源。
一、先搞懂三类核心连接的实际效果
别死记语法，看数据结果最直观：
-
INNER JOIN：只保留两表都有的匹配行。比如用户表和订单表关联，结果里不会出现没下单的用户，也不会出现找不到用户的订单。
-
LEFT JOIN：以左表为基准，右表匹配得上就填数据，匹配不上就补NULL。例如查所有用户+他们的订单数，没下单的用户订单字段显示NULL，但人还在结果里。
-
RIGHT JOIN很少用——它只是LEFT的镜像，多数情况改写成LEFT更易读（把原右表挪到左边即可）。
二、标准四步操作流程（顺序不能乱）
很多问题出在步骤颠倒，比如先写SELECT再想关联逻辑：
-
第一步：确认主表和从表——谁是你要展示的主体？比如“查每个部门的平均薪资”，部门表是主表，员工表是从表。
-
第二步：找关联字段并验证唯一性——用dept_id关联？检查员工表里dept_id是否都存在于部门表；部门表中dept_id是否重复（若重复，LEFT JOIN会引发笛卡尔积）。
-
第三步：写JOIN + ON，立刻加WHERE筛主表——如需“只看在职部门”，WHERE dept.status = 'active' 必须放ON之后、GROUP BY之前，否则LEFT JOIN可能漏掉本该保留的主表记录。
-
第四步：聚合前先处理NULL——用LEFT JOIN后，COUNT(emp.id)会跳过NULL，但COUNT(*)不会。算人数建议用COUNT(emp.id)，算总记录数才用COUNT(*)。
三、三个高频误区及对应解法
这些错误不报错，但结果离谱：
-
ON里混用WHERE逻辑：比如LEFT JOIN后写WHERE emp.salary > 5000，会把salary为NULL的主表记录也过滤掉——实际应写成ON ... A
ND emp.salary > 5000 或在SELECT里用CASE WHEN处理。
-
多表JOIN时ON条件错挂表：A JOIN B ON A.x=B.x JOIN C ON B.y=C.y —— 若C依赖A的字段，却写成ON C.a=A.a，可能因B中间结果已丢失A字段而报错或结果异常。原则：每个ON只关联当前新加入的表与已有结果集中的某张表。
-
没意识到JOIN顺序影响性能和语义：小表驱动大表更高效；LEFT JOIN后接INNER JOIN，整个结果受INNER约束——比如用户 LEFT JOIN 订单 INNER JOIN 订单明细，最终结果里用户必须有订单且订单必须有明细，等价于用户 INNER JOIN 订单 INNER JOIN 订单明细。
四、一个真实简化案例对照
目标：列出所有城市名称，以及每个城市下活跃店铺数量（无店铺的城市也要显示）
- ❌ 错误写法：
SELECT city.name, COUNT(store.id)
FROM city
LEFT JOIN store ON city.id = store.city_id
WHERE store.status = 'active';
→ WHERE让没店铺的城市被全过滤掉，LEFT失效。
- ✅ 正确写法：
SELECT city.name, COUNT(store.id)
FROM city
LEFT JOIN store ON city.id = store.city_id AND store.status = 'active'
GROUP BY city.id, city.name;
→ 把状态筛选放进ON，保留城市，只关联符合条件的店铺。
基本上就这些。关联本身不复杂，但容易忽略逻辑层级和NULL的连锁反应。动手前多问一句：“我到底要保留哪张表的全部记录？”答案出来，JOIN类型和ON位置基本就定了。
ND emp.salary > 5000 或在SELECT里用CASE WHEN处理。