ki-pi干了这么多年SQL，SQL JOIN 是我见过新手问得最多、老手也经常踩坑的一类操作。网上介绍内连接、外连接、交叉连接的文章一抓一大把，但大部分停留在"给我一张图、给我一段代码"的层面，真正把关联逻辑、过滤时机、执行原理和排查方法串起来讲透的少之又少。更别提那种"报错 [22000]: 超出全局hash join空间，适当增加hj_buf_global_size"的实战问题，文档里翻不到，百度也搜不太到靠谱答案。
这篇文章我打算换个讲法：用一套完整的客户表和订单表演示三种连接方式，把"什么时候该用哪个连接""ON和WHERE里的条件到底差在哪""JOIN跑得慢甚至内存溢出该怎么办"这些实际工作中绕不开的问题一次说清楚。内容偏实操，MySQL、PostgreSQL、openGauss 这类数据库的通用写法我尽量覆盖，你拿到本地能直接跑，跑完再看执行计划，理解会深很多。适合正在补 SQL 基础的数据分析师，也适合被慢查询和内存报错折磨的后端工程师。
1. 先理清楚：JOIN到底在做什么
1.1 回到最原始的笛卡尔积
很多教程一上来就给你画两个圆，左边一个右边一个，说交集就是内连接。图是好看，但容易让人形成一个错误认知：JOIN 是靠某种"魔法"把相关的行拼在一起。其实数据库没有那么聪明，它做的事情完全可以理解为"先把两张表里的每一行都和另一张表的每一行组合一遍，形成一个巨大的中间结果，再根据条件筛选保留需要的行"。
这个"每一行和每一行组合"的操作，就是笛卡尔积。举个例子，一张 10 行的表和一张 20 行的表做连接，如果什么都不限制，中间可能会形成一个 200 行的结果。JOIN 的本质就是在笛卡尔积的基础上，通过 ON 后面的关联条件把 200 行缩减到真正有意义的行。虽然现代数据库的优化器并不会真的傻到把笛卡尔积完整算出来，但理解这个模型，对后面理解连接算法、区分三种连接方式非常有用。
1.2 三种连接方式的本质区别
把概念浓缩成一句话：
INNER JOIN（内连接）：两边都匹配才会保留，否则丢弃。LEFT JOIN/RIGHT JOIN（外连接）：以一边为主，主表全保留，从表能匹配就匹配，匹配不上就补 NULL。FULL OUTER JOIN则是两边都全保留。CROSS JOIN（交叉连接）：不做任何匹配，直接生成笛卡尔积。
用一个表格对比会更直观：
| 连接方式 | 左表行 | 右表行 | 匹配成功 | 左表未匹配 | 右表未匹配 |
|---|---|---|---|---|---|
| INNER JOIN | 保留 | 保留 | 保留 | 丢弃 | 丢弃 |
| LEFT JOIN | 保留 | 保留 | 保留 | 保留，右列补NULL | 不保留 |
| RIGHT JOIN | 保留 | 保留 | 保留 | 不保留 | 保留，左列补NULL |
| FULL OUTER JOIN | 保留 | 保留 | 保留 | 保留，右列补NULL | 保留，左列补NULL |
| CROSS JOIN | 保留 | 保留 | 每行都组合 | 每行都组合 | 每行都组合 |
这个表看起来简单，但背后有一个特别容易踩的坑：关联字段有重复值时，JOIN 的结果行数不是你想当然的那个数。比如左表某客户 ID 出现 2 次，右表该 ID 也出现 3 次，内连接结果里这个客户就会出现 6 行。很多人写关联前不核对唯一性，结果统计出来的订单金额翻了好几倍，排查半天才发现是数据重复导致的。所以我在写任何 JOIN 之前，一定会先看一眼关联字段在两个表里的唯一性。
1.3 三句话理解为什么要用 JOIN
有人问，我明明可以用子查询，为什么非要 JOIN？我的经验是，JOIN 更适合横向扩展列，子查询更适合纵向过滤行。你要查"客户的姓名、电话、最近一笔订单金额"，订单金额在订单表里，姓名电话在客户表里，把这个两个表通过客户 ID 横向拼起来，就是 JOIN 的典型使用场景。你要是想查"哪些客户没下过单"，用 NOT EXISTS 子查询反而更高效，这也是后面会提到的选型问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三类连接方式的语法与实战代码
2.1 准备一套可直接复现的测试数据
纸上谈兵没意思，先建两张非常贴近业务的表：一张 customer 客户表，一张 orders 订单表。我故意把一个客户（id=4）完全不放在订单表里，再把一个订单的客户编号设置为 NULL，这样三种连接的差异会非常明显。
sql复制-- 客户表
CREATE TABLE customer (
customer_id INT PRIMARY KEY,
name VARCHAR(50),
phone VARCHAR(20)
);
INSERT INTO customer VALUES
(1, '张三', '13800000001'),
(2, '李四', '13800000002'),
(3, '王五', '13800000003'),
(4, '赵六', '13800000004'); -- 这个客户没有任何订单
-- 订单表
CREATE TABLE orders (
order_id INT PRIMARY KEY,
customer_id INT,
amount DECIMAL(10,2),
order_date DATE
);
INSERT INTO orders VALUES
(101, 1, 100.00, '2024-01-05'),
(102, 2, 250.50, '2024-01-07'),
(103, 1, 80.00, '2024-01-09'),
(104, 3, 300.00, '2024-01-12'),
(105, NULL, 66.00, '2024-02-01'); -- 这个订单无法对应客户
注意第二个插入语句里那个 customer_id = NULL 的订单。NULL 不会参与任何等值匹配，这是新手最容易忽略的点：NULL 和任何值用 = 比较都是不成立的。很多人在应用层看到某个订单客户编号为空，就以为 JOIN 能给它补上客户信息，其实在 SQL 里它会被直接丢掉或者补成 NULL。
2.2 内连接（INNER JOIN）：查交集
内连接是最常用的关联方式。需求很简单："查询所有有效订单，并显示订单对应的客户姓名和电话。"
sql复制SELECT
o.order_id,
o.amount,
c.name,
c.phone
FROM orders o
INNER JOIN customer c ON o.customer_id = c.customer_id;
拿上面造的数据跑一遍，结果会是 3 行：订单 101、102、103、104 里，除了客户 1 和 2、3 能匹配上，104 也能匹配上王五，实际上应该是 4 行（101/102/103/104），105 因为 customer_id IS NULL 匹配不上，所以不会出现在结果里。
这个例子告诉我们内连接的两个特征：
- 只要一边匹配不上，整行直接消失。
- 结果行数取决于两边的匹配情况，而不是左表或右表本身的记录数。
工作中常见的内连接场景包括：订单关联商品取商品名称、学生表关联成绩表取分数、日志表关联维表补全维度字段。需要注意，如果关联字段里有重复值，内连接会出现行数膨胀，所以写 JOIN 前做唯一性核对，比写完之后对着结果看半天更高效。
2.3 左外连接 / 右外连接（LEFT JOIN / RIGHT JOIN）：以一边为准
左外连接的需求非常多，几乎所有"查主表但也要带出从表信息"的场景都用它。典型需求："列出所有客户，并统计每个客户的订单总金额，没有下过单的客户也要展示，订单金额显示为 0 或 NULL。"
sql复制SELECT
c.customer_id,
c.name,
SUM(o.amount) AS total_amount
FROM customer c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name
ORDER BY c.customer_id;
结果会包含客户 4，赵六这行 total_amount 是 NULL，因为它在订单表里一条记录都匹配不到。很多人在做金额统计时会发现空值是 NULL，前端显示出来就是空白，解决办法是用 COALESCE(SUM(o.amount), 0) 或者 IFNULL。
这里有一个我踩过好几次的坑：SUM 和 GROUP BY 一起用的时候，如果把 name 放在 GROUP BY 里，但 SELECT 的字段和 GROUP BY 不一致，某些数据库会直接报错。所以在写这种统计时，我习惯把 GROUP BY 的字段写全，避免 only_full_group_by 模式的报错。
右外连接其实和左外连接是对称的，语义就是右表所有行都保留。实际开发中写 RIGHT JOIN 的人很少，因为大家习惯把主表写在左边，需要全保留的表就放前面然后 LEFT JOIN。不过当你要把两个表交换位置等价改写时，理解 RIGHT JOIN 还是有用的。
2.4 全外连接（FULL OUTER JOIN）：两边都保留
全外连接会把左表和右表中所有的行都拿进来，不匹配的补 NULL。最典型的业务场景是数据对账：你在比对两张表的数据差异时，既要看左表有而右表没有的，也要看右表有而左表没有的。
sql复制SELECT
c.customer_id,
o.order_id
FROM customer c
FULL OUTER JOIN orders o ON c.customer_id = o.customer_id
ORDER BY c.customer_id, o.order_id;
这个语句在 PostgreSQL、Oracle、SQL Server 里能直接跑，但 MySQL 8.x 依然不支持 FULL OUTER JOIN，需要拼两个 JOIN：
sql复制SELECT
c.customer_id,
o.order_id
FROM customer c
LEFT JOIN orders o ON c.customer_id = o.customer_id
UNION ALL
SELECT
c.customer_id,
o.order_id
FROM customer c
RIGHT JOIN orders o ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL;
注意第二段必须加 WHERE c.customer_id IS NULL，否则 UNION 之后数据会重复。这个方法虽然土，但在没有 FULL JOIN 的数据库里就是标准答案。
2.5 交叉连接（CROSS JOIN）：别小看它
交叉连接就是把两张表做笛卡尔积，不加任何条件。生产环境里直接 CROSS JOIN 两张业务大表是灾难级的操作，但它在两个场景下用起来很香。
第一个场景是生成测试数据。你想要 1000 个测试用户，手写 1000 条 INSERT 不现实，用系统表或者数字辅助表交叉生成非常快。假设 t1 有 10 条记录（0-9），t2 有 10 条记录（0-9）：
sql复制SELECT
a.digit * 10 + b.digit AS user_id,
CONCAT('test_', a.digit * 10 + b.digit) AS user_name
FROM t1 a
CROSS JOIN t2 b
ORDER BY user_id;
第二个场景是日期补全。统计网站上每天的用户访问量，如果某天没人访问，明细表里就没有这一天。为了在报表里把缺失日期补成 0 而不是直接消失，可以先构造一个日期序列表，再 LEFT JOIN 访问明细，这背后其实也用到了类似笛卡尔积的思路。日期序列的构造有很多方式，递归 CTE 或者连接数字辅助表都行，CROSS JOIN 在这里能帮上大忙。
3. ON 与 WHERE：外连接场景下的隐形杀手
3.1 同样一段 LEFT JOIN，结果差了很多
我见过太多人把条件一股脑塞进 WHERE，结果 LEFT JOIN 变成了"伪左连接"，左表的主表地位被破坏。看一段最典型的错误代码：
sql复制-- 需求：查所有客户，以及他们在 2024-01-01 之后的订单金额
SELECT
c.customer_id,
c.name,
o.amount
FROM customer c
LEFT JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= '2024-01-01';
这条 SQL 的结果会让你大吃一惊：客户 1、2、3 都还有，但客户 4（赵六）消失了，因为他在订单表里连匹配行都没有，而 WHERE 又把 o.order_date 过滤成了 NULL。LEFT JOIN 的语义说好要保留左表全部行，结果 WHERE 条件把不符合条件的补 NULL 行全删掉了，这和我想要的"所有客户都出现"完全不一样。
正确的写法是：如果过滤条件要限制"从表"但保留主表所有行，要把条件写在 ON 里面：
sql复制SELECT
c.customer_id,
c.name,
o.amount
FROM customer c
LEFT JOIN orders o ON c.customer_id = o.customer_id
AND o.order_date >= '2024-01-01';
这时客户 4 依然会出现，他的 o.amount 是 NULL，因为订单那边没有满足条件的数据。
3.2 为什么内连接里 ON 和 WHERE 等价
内连接的处理逻辑是两边都匹配才保留，不管过滤条件放在 ON 里还是 WHERE 里，最终都会被当作连接的一部分来过滤。所以很多 SQL 优化器遇到 INNER JOIN 时会直接把 ON 和 WHERE 的条件统一处理，结果一致。
这个差异最经典的记忆方法：LEFT JOIN 是先连接后过滤，WHERE 是对连接后的结果做终审。你要清楚，自己到底是想"剔除主表行"，还是"只影响从表字段值"。前者用 WHERE，后者用 ON。
3.3 实战中如何快速判断条件位置
我平时写复杂报表的时候，会先问自己三个问题：
- 这个查询的主表是谁？结果里哪张表的记录必须一条都不能少？
- 过滤条件如果直接作用于从表字段，会不会把主表本来要保留的行误伤？
- 如果计数发现 JOIN 后的行数比主表行数少，多半就是 WHERE 把主表行干掉了。
想清楚这几个问题，90% 的 LEFT JOIN 数据丢失问题都能避免。
4. 连接算法与大数据量性能优化
4.1 优化器底层主要有三种连接算法
SQL 是声明式语言，你只需要说"我要什么"，数据库自己决定"怎么取"。但了解执行计划里的连接算法，才能在出问题时快速定位。常见的有三种：
- 嵌套循环连接（Nested Loop Join）：适合小表驱动大表，逐行去匹配另一张表，必要的时候走索引。这种连接在数据量小、关联字段有索引时效率不低。
- 哈希连接（Hash Join）：适合两个表数据量都不小、且没有合适索引的等值连接。数据库先把小表读进内存建哈希表，再扫描大表逐行去哈希表里探测匹配。这就是报错 [22000]: 超出全局hash join空间 的源头。
- 合并连接（Merge Join）：适合关联字段已经排好序的场景，两边同时排序、同时推进，类似归并排序，效率稳定但要求数据有序或愿意付出排序代价。
如果你看到一条 SQL 在大表关联时走了嵌套循环而且驱动表选错了，性能可能会慢几个数量级。这时候第一步不是急着加索引，而是看 SQL 里能不能把过滤条件写得更收敛，把小结果集放在驱动侧。
4.2 哈希连接为什么需要内存
哈希连接的核心在于"建哈希表"这个动作。数据库会选择参与连接的两张表里较小的一张，读入内存，按关联字段算哈希值，在内存里构建一个哈希表；然后再扫描另一张大表，每读一行就去内存哈希表里探测。整个过程速度快，但内存消耗是可以预见的。
如果构建侧的这张表太大，内存里放不下，数据库会怎么做？通常是使用临时文件进行落盘，分批处理。这会导致频繁的磁盘 IO，速度断崖式下降。更严重的是，如果全局哈希连接缓冲区被撑满、并且没有设计好落盘机制，数据库就会直接抛出类似 sql 错误 [22000]: 超出全局hash join空间,适当增加hj_buf_global_size 的报错。
这个报错我在做数仓任务的时候遇到过。不是 SQL 语法错误，而是执行资源不够。报错信息里的 hj_buf_global_size 就是全局哈希连接缓冲区大小，它约定了并发哈希连接任务总共能使用的内存上限。
4.3 遇到 hash join 空间超限怎么办
先把报错理解清楚：超出全局hash join空间 的意思是，当前会话里某个哈希连接需要的内存超过了数据库允许的全局 hash join 缓冲区，常见于两张百万、千万级大表做等值关联的场景。报错也给了最直接的提示：调大 hj_buf_global_size。
以我常用的一款数据库为例，调整方式大致如下：
sql复制-- 查看当前大小
SHOW hj_buf_global_size;
-- 修改为 2GB（示例值，按实际内存评估）
SET hj_buf_global_size = 2GB;
不同数据库对这个参数的叫法不一样，有的叫 work_mem，有的叫 hash_buf，修改方式也有全局生效和会话生效之分，具体以你使用的数据库官方文档为准。但是千万不要无脑调大。全局内存有限，调得过大，并发一多其他查询没内存可用，反而拖垮整个实例。
我的经验是分三步走：
- 先确认是不是真的走了哈希连接，用
EXPLAIN看执行计划，确认 build 侧和 probe 侧分别是哪张表。 - 尝试在业务层缩减数据量。把必要的时间分区条件加上，只取需要的字段，能不能把大表先缩小到合理范围。
- 如果数据量确实无法压缩，再考虑调整参数。调参时先给一个相对保守的值，观察内存压力和查询耗时，慢慢上调。
另外一个非常有效的 SQL 层优化方法是：使用临时中间表，把大表关联拆成"先过滤、后关联、再汇总"的多段操作。比如先按日期把订单表过滤到当月的几百行，再关联客户维度表，哈希连接需要的缓冲区会大大降低。我在实际数据加工中多次靠拆分 SQL 避免了大促期间的内存超限，效果比单纯调参更稳。
4.4 从执行计划判断连接性能
在所有数据库里，执行计划都是调优的核心抓手。MySQL 用 EXPLAIN，PostgreSQL 用 EXPLAIN ANALYZE，openGauss 用 EXPLAIN PERFORMANCE。看执行计划的时候，我重点看三列：
- 扫描方式：是全表扫（Seq Scan）还是索引扫（Index Lookup）。多表关联时如果大表是 Seq Scan，大概率有问题。
- 连接方式：Nested Loop、Hash Join 还是 Merge Join。数据量大时 Hash Join 本身不是问题，问题在于 build 表过大。
- 实际行数与预估行数：差距过大说明统计信息过期，需要
ANALYZE刷新统计信息。
很多慢 SQL 的根因根本不是 JOIN 语法，而是统计信息不准导致优化器选错了驱动表。这时候调 SQL 没多大意义，跑一遍统计信息刷新任务，执行计划可能瞬间正常。
5. 高频踩坑与排查速查表
5.1 内连接结果行数远大于预期
原因：关联字段在某个表里不是唯一的。比如客户表里客户 ID 应该唯一，但脏数据导致同一个客户 ID 出现多条。内连接会做笛卡尔级组合，行数等于两边匹配次数的乘积。
排查思路很简单：先用 SELECT customer_id, COUNT(*) FROM 表 GROUP BY customer_id HAVING COUNT(*) > 1 查一下关联字段的重复情况。如果确实有重复，需要决定业务上保留哪一条，可以用 ROW_NUMBER() 窗口函数按主键顺序去重。
5.2 LEFT JOIN 后主表丢数据
这是 3.1 讲的 WHERE 条件误伤主表。排查时把 WHERE o.xxx IS NOT NULL 这类从表条件挪到 ON 里试试。注意，你要是真需要"只查那些有匹配行的用户"，那本来就不应该用 LEFT JOIN，改成 INNER JOIN 或者 EXISTS 更清晰。
5.3 使用内连接代替 IN 子查询的疑问
有个场景：查"下了单的客户"，你可以用 WHERE customer_id IN (SELECT customer_id FROM orders)，也可以用 INNER JOIN。数据量不大时两者都行，数据量大时 INNER JOIN 往往更容易走哈希连接。但 IN 子查询的语义更直白，什么时候用哪个主要看执行计划的成本。
5.4 一张速查表帮你快速定位
| 现象 | 可能原因 | 解决措施 |
|---|---|---|
| JOIN 结果行数爆炸 | 关联字段重复 | 先查重复，考虑 ROW_NUMBER 去重或聚合后再关联 |
| LEFT JOIN 后主表行数减少 | 过滤条件在 WHERE 且过滤从表字段 | 把从表过滤条件移到 ON 子句 |
| 全外连接不生效 | 数据库不支持 FULL OUTER JOIN | 用 LEFT JOIN UNION ALL RIGHT JOIN |
| JOIN 很慢且走了全表扫 | 缺少索引或统计信息过期 | 建关联字段索引，刷新统计信息 |
| 大表关联报 hash join 内存不足 | 哈希连接构建侧过大 | 调 hj_buf_global_size，拆分 SQL 缩小数据量 |
| 金额统计出现未知翻倍 | 一对多关联导致重复计算 | 先做明细级去重，再 JOIN，最后聚合 |
| 某些行关联不上 | 关联字段存在 NULL | 用 IS NULL 单独处理，或 COALESCE 转换后关联 |
这张表算是比较全面的实战总结，遇到问题先对应上面现象自查。很多情况下问题不是 JOIN 本身，而是数据质量。
5.5 写关联时我习惯遵守的几个原则
第一，先确认主表。谁的全量数据必须保留，谁做辅助，想清楚再写。第二，能小表驱动大表就小表驱动。但这是优化器的事，应用层更重要的任务是给足过滤条件，把小结果集交上去。第三，关联字段优先选择有约束或有索引的字段，避免隐式类型转换。比如一边是 VARCHAR 一边是 INT，数据库可能会对全表做转换，索引失效的同时也增加了内存压力。第四，不要写 SELECT *，多取一列就多一分内存和 IO 压力，尤其是在大表 JOIN 时。
6. 调参之外的体感与建议
写 JOIN 这么多年，我的体感是：语法本身两小时就能学会，真正拉开差距的是对数据形态和执行过程的感知。同样一条查询，在数据量、数据分布、索引情况都不同的环境里，执行计划可能截然相反。你无法控制优化器，但你可以通过建索引、清理重复数据、合理放置过滤条件来引导它走更优的路径。
前面提到 hj_buf_global_size 这个参数，我最后再补一点个人经验。调参之前，务必先看一眼当前实例有多少物理内存、有多少并发查询同时在跑。只盯着一个 SQL 调大全局缓冲区，很可能救了一个查询，坑了一批查询。更靠谱的办法是把这个 SQL 拆小，让它在内存可控的范围内完成，比任何调参都稳。如果你的环境里这个参数是会话级的，可以临时在当前会话调大去验证效果，确认有效后再评估是否全局调整。
如果你想进一步扩展思路，可以把这三个连接方式应用到真实业务里：用 LEFT JOIN 做流失客户分析（找出没有新订单的老客户），用 INNER JOIN 做核心成交客户清单，用 CROSS JOIN 配合递归做日期维度补全。每次写 JOIN 前，先问自己一句：我要保留哪张表的全部记录？两个关联列是否唯一？过滤条件应该出现在 ON 还是 WHERE？这三个问题想明白了，JOIN 就不会再坑人。