抹茶柚子冰事情要从我在群里回答一个问题说起。有人贴了两条 SQL，一条是 inner join，另一条是 left join，然后问我：这两条结果行数一样，为什么还要分两种？
这个问题看起来基础，实际上戳中了很多写 SQL 的人共同的弱点——JOIN 不是语法不会写，而是语义边界不清楚。我见过不少写了三五年 SQL 的人，提起 JOIN 能背出"内连接取交集、外连接带主表、交叉连接是笛卡尔积"，可真到了排查一个行数翻倍的报表时，照样抓瞎。你问他和 left join 和 inner join 什么时候结果等价、什么时候差十万八千里，他说不清楚。
所以这篇东西的定位就不是入门教程，而是把内连接、外连接、交叉连接这些 JOIN 家族成员，从"背定义"推进到"懂逻辑"。我会用一套固定的案例数据，把每种 JOIN 的产生、执行过程、结果形态和踩坑点全部摊开来讲，配上可直接运行的 SQL 代码。适合刚学完 JOIN 基本语法、但想彻底理顺语义的初学者，也适合天天写 SQL 但偶尔被多表关联搞到怀疑人生的业务开发。
1. 造一张不容易"骗自己"的测试表：数据设计里藏了五个坑
学 JOIN 最容易犯的错误是拿"完美数据"练手——两张表的主键一一对应，每条记录都能匹配上，跑出来结果都一样，然后你自以为领悟了，实际什么都没学到。要真正搞懂内连接和外连接的区别，表里必须同时存在三类数据：能匹配上的、左表有但右表没有的、右表有但左表没有的。缺了任何一类，你看到的执行结果都有迷惑性。
1.1 表结构设计：让"匹配得到"和"匹配不到"同时出现
我设计了两张极简业务表：users（用户表）和 dept（部门表）。用户表里每个用户挂一个 dept_id，部门表里存部门信息。这个模型非常贴近真实场景——用户可能没有分配部门，部门也可能暂时没有成员，这就天然形成了 JOIN 的边界测试数据。
sql复制-- MySQL 8.0 语法，SQL Server / PostgreSQL 改一下字符串类型即可
CREATE TABLE dept (
id INT PRIMARY KEY,
dept_name VARCHAR(50) NOT NULL
);
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
dept_id INT NULL
);
INSERT INTO dept (id, dept_name) VALUES
(101, '研发部'),
(102, '市场部'),
(104, '人事部');
INSERT INTO users (id, name, dept_id) VALUES
(1, '张三', 101),
(2, '李四', 102),
(3, '王五', NULL),
(4, '赵六', 103),
(5, '钱七', 101);
注意我刻意埋的几个雷：
users表里王五的dept_id是NULL，对应"用户没有部门"；赵六的dept_id是103，但部门表里根本没有103，对应"用户指向了不存在的部门"（业务上可能是脏数据，也可能是部门已删除但用户没同步）；dept表里有104 人事部，但没有任何用户挂在它下面，对应"空部门"。
这三个条件同时具备，你才能在同一套数据上观察到 JOIN 类型对结果集的影响。如果只造"能匹配上"的数据，跑完 inner join 和 left join 行数一模一样，谁也看不出区别，也练不出排查的感觉。
1.2 明确样例数据分布，后面每一步都能核对
列一下后续所有 SQL 的预期基准：
users共 5 行；dept共 3 行；- 两表能通过
users.dept_id = dept.id匹配上的，只有 3 行：张三→研发部、李四→市场部、钱七→研发部； 王五（无部门）、赵六（指向 103）在部门表里没有归属记录；104 人事部在用户表里没有任何成员。
所以内连接的正确答案是 3 行，左连接是 5 行，交叉连接是 5 × 3 = 15 行。拿着这三组预期数字去验证你写的 SQL，比盲跑工具然后看着结果猜逻辑要有效得多。
提示：学 JOIN 自己练习时，强烈建议先手算出预期结果再执行。执行结果和你预期不一致时，不要急着改 SQL，先搞清楚是哪张表的哪一行数据导致数量变化，这个过程才是涨功力的地方。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 内连接（INNER JOIN）：为什么它默认"两边都要有"才算数
内连接的语义用一句话讲：只保留左右两张表中满足连接条件的记录。说"交集"不算全对——它更准确的说法是：对左表的每一行，去右表里找"符合 ON 条件"的行，找到就拼成一行输出，找不到就丢弃。
2.1 ON 子句的匹配过程，是逐行"配对"而不是整体"求交"
很多人以为 JOIN 像集合运算中的 INTERSECT，先把两张表分别算出来再取公共部分。其实数据库执行等值连接时，通常的行为是嵌套循环或者哈希匹配——你可以理解为拿着左表的一行，去右表里搜匹配行。这就解释了为什么 JOIN 之后行数可能超过左表：如果左表一行在右表里匹配到多行，结果集就会翻倍放大。
sql复制-- 标准的显式内连接
SELECT u.id AS user_id,
u.name AS user_name,
u.dept_id,
d.id AS dept_id,
d.dept_name
FROM users u
INNER JOIN dept d ON u.dept_id = d.id;
这段 SQL 的执行逻辑，我习惯拆成三步理解：
- 从
users取第一行（比如张三，dept_id = 101）； - 拿
101去dept表找id = 101的部门，找到了就拼一行； - 如果找不到（比如赵六的
103），整行直接丢弃，不出现在结果里。
所以最终输出是 3 行。这里有一个新手常犯的认知错误：他们以为 INNER JOIN 会保留"两张表都出现过的部门"。实际上它保留的是"有用户且用户指向的部门存在"的组合，而一张空部门表 104 人事部 虽然存在，因为没有用户指向它，也不会出现在内连接结果里。
2.2 老式"逗号连接"与 INNER JOIN：语法等价，但别在生产里混用
早年的 SQL 写法里，内连接不写 JOIN，而是直接在 FROM 后放多张表，用 WHERE 写关联条件。这种写法叫"隐式内连接"：
sql复制-- 隐式内连接（老式写法）
SELECT u.id, u.name, d.dept_name
FROM users u, dept d
WHERE u.dept_id = d.id;
这段 SQL 和前面的 INNER JOIN ... ON 结果完全一样。但我不建议你在新代码里这么写，原因有两条：
- 如果哪天你忘了写
WHERE，它就会直接从内连接堕落成交叉连接，返回 5 × 3 = 15 行，而 SQL 本身不会报任何错——这是"隐式连接"最危险的地方； - 当表多了之后，
WHERE里同时混合连接条件和过滤条件，阅读的人很难分辨哪个是关联、哪个是筛选，维护成本直线上升。
所以现代 SQL 规范里，显式 INNER JOIN ... ON 是绝对的主流，它把"表怎么连"和"行怎么筛"分开表达，清晰太多。
2.3 内连接的条件不等于只能写等号：非等值连接也有用武之地
一说到 JOIN，很多人第一反应就是主键等于外键。但 ON 后面的条件可以是任意布尔表达式，除了 =，还能用 >、<、BETWEEN 等。这类"非等值连接"在区间匹配场景里非常实用。
比如我要给用户根据部门编号段打标，把 100~102 的用户归为"核心区"，103~105 归为"扩展区"：
sql复制CREATE TABLE dept_region (
region_name VARCHAR(20),
min_id INT,
max_id INT
);
INSERT INTO dept_region VALUES
('核心区', 100, 102),
('扩展区', 103, 105);
SELECT u.name, u.dept_id, dr.region_name
FROM users u
INNER JOIN dept_region dr
ON u.dept_id BETWEEN dr.min_id AND dr.max_id;
王五 的 dept_id 为 NULL，比较结果为未知（UNKNOWN），不会进入结果集；赵六 的 dept_id 是 103，落在"扩展区"，输出一行。这种写法在订单金额区间、考试成绩分段、IP 地址归属等场景中经常用到——意识到"连接的字段不一定是键，连接的条件不一定是等号"，你对 JOIN 的理解才算及格。
2.4 ON 和 WHERE 在内连接里可以互换，但语义上该有分工
内连接里把条件写在 ON 和写在 WHERE，最终结果是一样的。下面两句返回相同结果：
sql复制SELECT u.name, d.dept_name
FROM users u
INNER JOIN dept d ON u.dept_id = d.id
WHERE d.dept_name = '研发部';
SELECT u.name, d.dept_name
FROM users u
INNER JOIN dept d
ON u.dept_id = d.id AND d.dept_name = '研发部';
第一句逻辑是：先连接，再过滤研发部。第二句逻辑是：连接时只连接研发部的部门记录，其他部门直接不参与连接。由于内连接本身会丢弃匹配不到的行，这两种顺序殊途同归。但等我们看到外连接时就会明白，这个"等价性"只在 INNER JOIN 里成立，一旦换成 LEFT JOIN，写在 ON 和写在 WHERE 就是一个天一个地。这点我在第 3.4 节会详细展开。
3. 外连接：核心是"谁当老大"，不是"带不带空值"
如果说内连接是"两边都认账才留"，那么外连接的核心思想就是以一张表为基准（驱动表），它的每一行都必须出现在结果里，匹配不到就用 NULL 补齐。但这个基准关系，恰恰是很多人没有真正建立起来的。
3.1 LEFT JOIN 语义拆解：五行的 users 一定输出五行
sql复制SELECT u.id AS user_id,
u.name AS user_name,
u.dept_id,
d.id AS dept_id,
d.dept_name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id;
执行过程用大白话说就是：
users是左表，是"老大"，它的 5 行不管能不能在dept里找到对应部门，都会输出；张三、李四、钱七能找到部门，正常拼接；王五的dept_id是NULL，拿NULL去等于任何值的结果都是未知（不是FALSE），所以匹配不上，输出时dept那一侧全是NULL；赵六的dept_id是103，但dept表里没有 103，同样匹配不上，输出时右侧为NULL。
最终结果 5 行，其中 3 行两表都有值，2 行右表列为空。这就是"左外连接以左表为主体"的直观体现。
结果大致如下：
| user_id | user_name | dept_id | dept_id | dept_name |
|---|---|---|---|---|
| 1 | 张三 | 101 | 101 | 研发部 |
| 2 | 李四 | 102 | 102 | 市场部 |
| 3 | 王五 | NULL | NULL | NULL |
| 4 | 赵六 | 103 | NULL | NULL |
| 5 | 钱七 | 101 | 101 | 研发部 |
这张表请记住，它是判断你后面所有"左连接带条件" SQL 的基准线。
3.2 内连接 PK 左连接：同一条 SQL 换一个词，结果为什么从 3 行变 5 行
我把前一节的 INNER JOIN 和 LEFT JOIN 放一起对比：
INNER JOIN保留"能匹配上的 3 行"；LEFT JOIN保留"左表全部 5 行，其中 2 行补 NULL"。
两者相差的 2 行，正是 王五 和 赵六 这两条在部门表里没有归属的记录。在内连接的世界里，他们是"不存在"的；在左连接的世界里，他们是"存在但缺信息"的。
这个差异在业务统计里非常关键。比如算"每个部门的人数"，如果用内连接，王五 和 赵六 直接人间蒸发，统计出的总数比 users 表少；如果先 LEFT JOIN 再按部门分组，就能保证所有用户都参与统计，只是无部门的用户被归到一组 NULL 里。后者往往才是业务想要的"全量用户视角"。
3.3 RIGHT JOIN 和 FULL JOIN：不是新知识，而是同一个语义换个方向
RIGHT JOIN 就是把"老大"换成了右表。它查出的行数以右表为基准，等于左连接把两表位置互换后的结果。实际开发中用到 RIGHT JOIN 的机会远少于 LEFT JOIN，因为人们习惯把主表写在左边。但这不代表它可以不会——当你接手老系统看到 RIGHT JOIN 时，把它脑补成"把表换边、LEFT JOIN 重写一遍"即可。
sql复制-- 等价写法一：RIGHT JOIN
SELECT u.name, d.dept_name
FROM users u
RIGHT JOIN dept d ON u.dept_id = d.id;
-- 等价写法二：左右调换后的 LEFT JOIN
SELECT u.name, d.dept_name
FROM dept d
LEFT JOIN users u ON u.dept_id = d.id;
这两句结果完全一致：右表 dept 的 3 行全部保留，其中 104 人事部 没有员工，左侧 u 字段为 NULL，所以输出 3 行。
FULL OUTER JOIN 是"两边都当老大"——左边补右、右边补左，所有行都保留，匹配不上的两侧交替出现 NULL。要注意的是 MySQL 8.0 及以下不直接支持 FULL OUTER JOIN，需要用 LEFT JOIN UNION RIGHT JOIN 模拟；而 PostgreSQL、SQL Server 都原生支持。
sql复制-- MySQL 模拟 FULL OUTER JOIN
SELECT u.id, u.name, u.dept_id, d.id, d.dept_name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id
UNION
SELECT u.id, u.name, u.dept_id, d.id, d.dept_name
FROM users u
RIGHT JOIN dept d ON u.dept_id = d.id;
UNION 会去重，所以能模拟出 6 行：3 行能匹配 + 2 行只有用户无部门 + 1 行只有部门无用户。
3.4 外连接中最容易翻车的点：ON 里的过滤条件和 WHERE 里的过滤条件"身价不同"
这个问题值得单独拿出来强调，因为它坑过太多人。在 INNER JOIN 里，条件写在 ON 和写在 WHERE 等价；但在 LEFT JOIN 里，两者天差地别。
看这段 SQL，目的是查"所有用户里，属于研发部的人有哪些"：
sql复制-- 写法 A：部门过滤写在 WHERE
SELECT u.name, d.dept_name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id
WHERE d.dept_name = '研发部';
执行过程：先做左连接，users 的 5 行全部拼接完成，得到 5 行中间结果（2 行右侧为空），然后 WHERE 把 dept_name = '研发部' 之外的行全部过滤掉。结果只剩 张三 和 钱七 两行。这个逻辑是对的。
再看写法 B：
sql复制-- 写法 B：部门过滤写在 ON
SELECT u.name, d.dept_name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id AND d.dept_name = '研发部';
执行过程完全变了：左连接在匹配 dept 表时，额外要求"部门名称必须是研发部"，市场部、人事部 从一开始就被排除在连接候选之外。李四 本来能匹配市场部，但因为 ON 条件限死了只连研发部，于是匹配不到，输出一行 (李四, NULL)。王五、赵六 同样匹配不到，输出 NULL。最终结果还是 5 行（因为左表行数不能丢），但只有 张三 和 钱七 真正带上了"研发部"，其他 3 行全部是 NULL。
这两种写法行数不同、业务含义不同。写法 A 是先连接成一张大宽表再筛行，写法 B 是"只要我最关心的那部分匹配数据"。放在"用户列表里标记是否研发部"的场景，写法 B 是对的；放在"筛选研发部用户列表"的场景，必须用写法 A。
提示：写
LEFT JOIN时，先问自己一个问题——"这个条件是用来决定连接哪些行的，还是用来从结果里剔除行的？"前者放 ON，后者放 WHERE。这个判断做错，结果集的行数和内容都会悄无声息地改变，而且不报错。
4. 交叉连接（CROSS JOIN）：它不该是事故，也可以是工具
交叉连接是所有 JOIN 里最容易理解的，也是最容易被骂的——因为它就是笛卡尔积：左表的每一行和右表的每一行两两组合。users 5 行、dept 3 行，交叉连接后输出 15 行，不做任何匹配。
4.1 CROSS JOIN 做一次让你"肉眼可见"的笛卡尔积
sql复制SELECT u.id, u.name, d.id, d.dept_name
FROM users u
CROSS JOIN dept d;
结果会有 15 行：每个用户 × 每个部门。哪怕张三只属于研发部，他也会和 "市场部""人事部" 各拼一行出现在结果里。执行过程本质上就是两层循环：外层遍历 users 每一行，内层遍历 dept 每一行，拼完为止。
有人一听到"笛卡尔积"当场变色，觉得这是性能灾难的代名词。实际上 CROSS JOIN 本身只是个工具，坏的不是笛卡尔积，而是你以为自己在做关联查询，结果忘了写连接条件，数据库默默帮你做了笛卡尔积。这两件事性质完全不同——一个是主动设计，一个是被动事故。
4.2 隐式交叉连接：不写 WHERE 的 FROM a, b 是最常见的生产事故
前面 2.2 节提到，老式写法 FROM users u, dept d 如果漏了 WHERE u.dept_id = d.id，会直接退化成笛卡尔积。而更新式的 SQL 标准把 JOIN 变成了强制关键字，CROSS JOIN 则让"我要做笛卡尔积"这件事从语法层面被显式表达出来。
我排查过很多次报表行数暴涨的问题，最后定位到的 SQL 长这样：
sql复制SELECT ...
FROM orders o
LEFT JOIN order_items i ON o.id = i.order_id
LEFT JOIN products p -- 这里 ON 条件被注释掉了，忘了补
第二个 LEFT JOIN 没有 ON 条件时，部分数据库会把它当作交叉连接处理，再把结果拼到左边，行数直接爆炸。这种问题在代码 review 阶段就应该拦下来，但现实里它经常以"SQL 能跑出结果，就是数字不对"的形式出现，异常隐蔽。养成两个习惯能有效避免：一是写 JOIN 必须带 ON，不写 ON 就等于想清楚你要笛卡尔积；二是关联查询跑完后，先看行数是否符合预期量级，再去看具体数值。
4.3 交叉连接的正经用途：数字序列、行转列和批量组合
CROSS JOIN 虽然名声不好，但在某些场景下它是最高效的解法。举三个我实际用过的：
数字序列：当你需要一张连续的 1 到 100 的数字表做"补齐缺失日期"时，可以先造 10 行的辅助表再交叉连接自己几次生成百位级序列，比循环插入快得多。
sql复制CREATE TABLE digit (d INT);
INSERT INTO digit VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
-- 生成 0~999 的连续数字
SELECT d1.d * 100 + d2.d * 10 + d3.d AS num
FROM digit d1
CROSS JOIN digit d2
CROSS JOIN digit d3
ORDER BY num;
行转列的桥接：某个商品有 3 个颜色、2 个尺寸，需要生成 6 个 SKU 的组合列表，交叉连接恰好是"排列组合"最直接的翻译。
构造测试数据：压测时需要快速放大数据量，交叉连接临时表可以轻松把几百行放大成几十万行。
注意：这些场景有一个共同点——我们需要的就是"无条件的两两组合"或"按规律组合"，不是误操作。用
CROSS JOIN显式表达意图，比FROM a, b不写条件安全得多，至少代码阅读者一眼就能看出这是故意的。
5. 外面传的"少用 JOIN"和"多表 JOIN 慢"，到底在说什么
"为什么大厂不建议使用多表 JOIN"这个话题常年挂在技术社区热榜上。大家天天刷到，但很多人只是记住了结论——少用 JOIN——却没搞明白背后的真正原因。这一节我想把它讲透，因为它和前面所有 JOIN 语义一脉相承。
5.1 JOIN 导致行数放大，才是性能问题的本质来源
先说结论：JOIN 本身不是洪水猛兽，无脑的多表 JOIN 最容易在"一对多"关系上引发中间结果集爆炸。
设想一个电商订单场景。订单表 orders 一行一个订单；订单明细表 order_items 一行一个商品明细，一个订单可能对应 3 个明细；支付流水表 payments 一行一次支付，一个订单可能被分多次支付。如果我把三张表一股脑 JOIN：
sql复制SELECT o.order_id, i.item_name, p.pay_amount
FROM orders o
LEFT JOIN order_items i ON o.order_id = i.order_id
LEFT JOIN payments p ON o.order_id = p.order_id;
假设某个订单有 3 个明细、2 笔支付流水，那么"明细"和"流水"会两两组合，这个订单在结果里不是 3 行也不是 2 行，而是 3 × 2 = 6 行。如果一张订单有 10 个明细、5 笔流水，这个订单就膨胀成 50 行。多个订单累加起来，中间结果集的行数会远超任何一张源表——我见过最夸张的案例，三张原始表都只有几万行，JOIN 完的中间结果膨胀到几千万行，查询直接跑挂。
这种放大效应会带来三个连锁问题：
- 占内存：数据库需要把中间结果放进内存或临时表，放大倍数越高，资源压力越大；
- 慢：嵌套循环连接的匹配次数跟着放大；
- 错：如果你在 JOIN 后的结果上直接做
SUM(pay_amount)，同一个支付金额会因为订单有 3 个明细而被累加 3 次，统计数字变大——这是语义错误，不是性能问题。
所以"大厂不建议多表 JOIN"，从来不是说 JOIN 这个语法应该被禁用，而是说：不要随手把七八张表 JOIN 成一张大宽表，再在大宽表上做聚合。更好的做法是拆分查询，或者先聚合明细再 JOIN，让 JOIN 发生在已经"瘦身"后的结果上。
5.2 单表聚合先行，再 JOIN：让结果集不再膨胀
拿上面那个订单场景举例，正确姿势是先按订单聚合支付金额，再 JOIN 订单主表：
sql复制SELECT o.order_id,
o.customer_name,
pay.total_amount
FROM orders o
LEFT JOIN (
SELECT order_id, SUM(pay_amount) AS total_amount
FROM payments
GROUP BY order_id
) pay ON o.order_id = pay.order_id;
子查询先把 payments 按订单压缩成一行，JOIN 时不会产生多对多的行数爆炸。同理，订单明细也应该先 SUM(item_cnt) 得到每个订单的商品件数，再 JOIN 主表。这么做，每一层 JOIN 两侧的粒度都是"一行对一行"，结果集的行数始终等于驱动表的行数。
这个原则可以总结为一句话：JOIN 之前，先把粒度对齐。粒度对齐了，行数不膨胀，性能自然不会差到哪去。
5.3 索引和连接字段的类型一致性，也不能忽视
抛开行数放大，还有一个常见的性能杀手是连接字段上没有索引、或者两侧字段类型不一致。以 users.dept_id 连接 dept.id 为例，如果 dept.id 是主键，已经有索引，那么 INNER JOIN 执行时对每个用户去主键索引里查找部门，速度快得飞起。但如果你连接两个都不是主键、又没有索引的字段，数据库只能对每一行做全表扫描，复杂度直线上升。
另外，dept_id 是 INT，而另一张表的 dept_id 是 VARCHAR，数据库会隐式做类型转换，导致索引失效。排查这类问题有个基本套路：执行计划里看到 Using join buffer、Using where 或者 type = ALL 这类信息，基本就能锁定索引没有用上。
提示：调试慢 SQL 时，先看 JOIN 有没有把一对多写成多对多，再看连接字段上有没有索引，最后看执行计划里有没有出现隐式类型转换。按照这个顺序排查，大概率能解决大部分"JOIN 慢"的问题。
6. 容易混淆的场景逐一拆解：左连接行数翻倍、重复数据和 NULL 过滤
这一节集中处理几个我在无数帖子和实际工单里反复见到的问题。这些问题单拎出来都不难，只是它们总是以组合形态出现，把写 SQL 的人绕晕。
6.1 LEFT JOIN 之后行数比左表还多，是不是 SQL 写错了
有位同事拿一条 SQL 找我，说"left join 之后居然比左表多了 3 行，left join 不是应该以左表为准吗？是不是数据库出 bug 了？"
我让他先看数据：左表是订单表，右表是订单退款表，一个订单确实可能发生多次部分退款。左连接保证的是"左表每一行都出现"，但没有承诺"左表每一行只出现一次"。当右表有 2 笔退款时，这个订单就会在结果里出现 2 行。也就是说，左连接的行数下限是左表行数，上限取决于右表里最大匹配次数。如果右表有 3 条匹配记录，左表的这一行就会展开成 3 行。
遇到这种情况，需要回到业务问题本身：你想查的是"每个订单的退款总额"，那就应该先对退款表按订单分组聚合成一行，再左连接；你想查的是"每一笔退款明细"，那行数膨胀就是预期行为，只是别拿这个结果再去 SUM 订单金额。
这也是我为什么在前面反复强调"先看粒度再看结果"——JOIN 的语义本身没有错，错的是用它的人没想清楚结果集的目标粒度。
6.2 直接 JOIN 重复数据：是先聚合还是先连接
上面这个场景延伸出一个高频设计问题：什么时候该先 GROUP BY、再 JOIN，什么时候先 JOIN 再 GROUP BY？
我给你的判断标准是："聚合是否依赖连接后的字段"。如果聚合只依赖右表自身的字段，先聚合再连接基本总是更好，因为它减小了 JOIN 一侧的数据量，绝不产生放大。比如查"每个部门有多少用户"，其实等价于先按 dept_id 数 users，再关联部门名称：
sql复制SELECT d.dept_name, cnt.user_count
FROM dept d
LEFT JOIN (
SELECT dept_id, COUNT(*) AS user_count
FROM users
WHERE dept_id IS NOT NULL
GROUP BY dept_id
) cnt ON d.id = cnt.dept_id;
反过来，如果聚合需要用到左表和右表连接后的值，比如"每个用户的部门名称拼接"，那你只能在 JOIN 之后做，或者交给数据库优化器去决定。大多数情况下，能在 JOIN 前缩小的数据，就不要拖到 JOIN 后。
6.3 过滤 NULL：外连接补出来的 NULL，经常被"不等于"条件误杀
最后提一个容易踩的过滤陷阱。假设你想找"用户不在任何部门"的人，直觉反应是：
sql复制SELECT u.name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id
WHERE d.dept_name != '研发部';
这段 SQL 大概率查不到你想要的结果。原因在于：王五 和 赵六 的左连接结果是右表全 NULL，而 NULL != '研发部' 的结果是 UNKNOWN（不是 TRUE），WHERE 只保留 TRUE 的行，所以这两行被过滤掉了。这正好呼应 3.4 节的问题——你本想保留"无部门"用户，但 NULL 值在比较运算里的特殊行为把它们排除了。
正确写法应该是明确判断 NULL：
sql复制SELECT u.name
FROM users u
LEFT JOIN dept d ON u.dept_id = d.id
WHERE d.dept_name IS NULL;
因为凡是 LEFT JOIN 后右表字段为 NULL 的行，就是左表在右表里没有匹配上的行。用 IS NULL 来判断"连接不上"是外连接里最标准的套路，几乎每天都会用到。
7. 最后分享一个 JOIN 排查的实战心法：永远先跑 COUNT，再对数据
回顾这篇讲的所有内容，你会发现所有 JOIN 的坑基本都落在两个点上：结果集行数的变化和NULL 值的行为。所以我自己正式跑业务 SQL 之前，一定先做两个动作：
- 先分别
SELECT COUNT(*)看左右表各自行数，再跑 JOIN 看结果行数——通过行数关系判断有没有发生一对多放大； - 把 WHERE 条件里的"排除项"逐条过一遍，凡是可能遇到 NULL 的字段，确认是否用了
IS NULL而不是!=。
每次排查多表关联问题，我都会在草稿纸上画一张"行数变化记录表"：左表多少行、右表多少行、JOIN 后多少行、过滤后多少行。哪个环节行数不符合预期，问题就出在哪个环节，基本一次定位，不用在 SQL 里来回试。这套方法我用了很多年，它比任何可视化工具都可靠——因为工具只能告诉你结果不对，不能告诉你哪一步开始不对。