MySQL 中的各种 JOIN

本文主要介绍 SQL 标准中定义的各种连接的意义和区别，例如，交叉连接（ CROSS JOIN ）、内连接（ INNER JOIN ）、外连接（ OUTER JOIN ）、自然连接（ NATURAL JOIN ）等，并结合例子讲解这些连接在 MySQL 中的语法和表现。

从网上的资料看， JOIN 更多翻译为连接，本文中凡是出现中文“连接”的地方都是指 JOIN 。

本文中用到的所有例子涉及两张表—— customers 用户表和 orders 订单表，其中订单表中的 cust_id 字段表示用户的唯一 ID，也就是用户表的主键 cust_id 。两张表的数据如下：

注：两张表都经过了简化，实际业务中这两张表肯定还包括其他字段。

英文维基百科 JOIN 词条 对连接的定义如下：

翻译过来就是，“连接可以根据一张（自连接）或多张表中的共同值将这些表的列数据合并为一个新的结果集，标准 SQL 定义了五种连接：内连接、左外连接、右外连接、全外连接和交叉连接。”

也就是说，连接是 SQL 标准中定义的一种组合多张表的方式，当然一张表自身也可以和自身组合，称为自连接。连接后得到的结果集的每一列其实都来自用于连接的多张表，不同的连接类型只是区分了这些列具体从哪张表里来，列里填充的是什么数据。

其实英文维基百科的 JOIN 词条已经把各种连接的类型解释地非常清楚了，非常值得去看一下。

我们来看一下 SQL 标准中定义的各种连接类型，理解各种连接最好的方法就是把需要连接的表想象成集合，并画出可以反映集合的交与并的情况的图——韦恩图，例如下图就画出了 SQL 中定义的几种主要连接。

请先仔细查看一下图中的内容，你可以从中归纳出几种连接类型呢？

虽然图中画了 7 种集合的交并情况，但是总结起来，主要是两种连接类型在起作用——内连接（ INNER JOIN ）和外连接（ OUTER JOIN ），其中外连接又分为了左外连接（ LEFT OUTER JOIN ）、右外连接（ RIGHT OUTER JOIN ）和全外连接（ FULL OUTER JOIN ）。

下面先简单介绍一下 SQL 标准中各种连接的定义，然后在「MySQL 中的连接」一节再用例子来演示 MySQL 中支持的各种连接。

连接既然是用来合并多张表的，那么要定义一个连接就必须指定需要连接的表，并指定可选的连接条件。例如，一个典型的 SQL 连接语句如下：

我们用表 A 和表 B 指代需要连接的两张表，经过 内连接 后得到的结果集 仅 包含所有满足 连接条件 的数据；而经过 外连接 后得到的数据集 不仅 包含满足 连接条件 的数据，还包含其他数据，具体的差别是：

在上面「SQL 标准定义的主要连接」一图中并没有列出交叉连接，交叉连接会对连接的两张表做笛卡尔积，也就是连接后的数据集中的行是由第一张表中的每一行与第二张表中的每一行配对而成的，而不管它们 逻辑上 是否可以搭配在一起。假设交叉连接的两张表分别有 m 和 n 行数据，那么交叉连接后的数据集就包含 m 乘以 n 行数据。

连接根据连接的条件不同，又可以区分为等值连接和非等值连接，「SQL 标准定义的主要连接」图中画出的连接的连接条件都是比较两个字段是否相等，它们都是等值连接。

自然连接是等值连接的一种特殊形式，自然连接会自动选取需要连接的两张表中字段名相同的 所有 列做相等比较，而不需要再指定连接条件了。

注：以下内容全部基于 MySQL 5.7 版本，所有例子只保证在 MySQL 5.7 上是可以正确执行的。

MySQL 中支持的连接类型和关键字如下：

上面的表示方法摘自 MySQL 5.7 版本 官方文档 ，其中 | 表示两者皆可出现， [] 表示的是可选的， {} 表示的是必选的，例如 NATURAL LEFT JOIN 和 NATURAL JOIN 都是合法的。

可以看到，除了全外连接（ FULL OUTER JOIN ）以外， MySQL 基本支持了 SQL 标准中定义的各种连接。在 MySQL 中全外连接可以通过 UNION 合并的方式做到，当然前提是你知道自己为什么需要这么做，具体参见： Full Out Join in MySQL 。

MySQL 语法中还支持一个并不在 SQL 标准中的 STRAIGHT_JOIN ，它在 表现上 和内连接或者交叉连接并无区别，只是一种给 MySQL 优化器的一个提示， STRAIGHT_JOIN 提示 MySQL 按照语句中表的顺序加载表，只有在你明确清楚 MySQL 服务器对你的 JOIN 语句做了负优化的时候才可能用到它。

还有一点需要说明的是，根据 官方文档 ，在 MySQL 中， JOIN 、 CROSS JOIN 和 INNER JOIN 实现的功能是一致的，它们在语法上是等价的。从语义上来说， CROSS JOIN 特指无条件的连接（没有指定 ON 条件的 JOIN 或者没有指定 WHERE 连接条件的多表 SELECT ）， INNER JOIN 特指有条件的连接（指定了 ON 条件的 JOIN 或者指定了 WHERE 连接条件的多表 SELECT ）。当然，如果你非要写 ... CROSS JOIN ... ON ... 这样的语法，也是可以执行的，虽然写着交叉连接，实际上执行的是内连接。

下面我们就用例子来看一看 MySQL 中支持的几种连接的例子。

注：下面的例子都没有指定 ORDER BY 子句，返回结果的顺序可能会因为数据插入顺序的不同而略有不同。

MySQL 的交叉连接或内连接有两种写法，一种是使用 JOIN 并用 ON 或者 USING 子句指定连接条件的写法，一种是普通的 SELECT 多表，并且用 WHERE 子句指定连接的键的写法。

下面的例子是一个交叉连接：

上面的写法等价于：

当然，第二种写法中如果将 CROSS JOIN 替换成 JOIN 或者 INNER JOIN 也是可以正确执行的。上面两条语句的执行结果如下：

可以看到共返回了 30 行结果，是两张表的笛卡尔积。

一个内连接的例子如下：

上面的写法等价于：

在连接条件比较的字段相同的情况下，还可以改用 USING 关键字，上面的写法等价于：

上面三条语句的返回结果如下：

可以看到只返回了符合连接条件 customers.cust_id = orders.cust_id 的 6 行结果，结果的含义是所有有订单的用户和他们的订单。

左外连接和右外连接的例子如下，其中的 OUTER 关键字可以省略：

其中右外连接的返回与内连接的返回是一致的（思考一下为什么），左外连接的返回结果如下：

可以看到一共返回了 8 行数据，其中最后两行数据对应的 order_id 的值为 NULL ，结果的含义是所有用户的订单，不管这些用户是否已经有订单存在了。

根据前面介绍的自然连接的定义，自然连接会自动用参与连接的两张表中 字段名相同 的列做等值比较，由于例子中的 customers 和 orders 表只有一列名称相同，我们可以用自然连接的语法写一个与上面的内连接的例子表现行为一样的语句如下：

可以看到，使用自然连接就不能再用 ON 子句指定连接条件了，因为这完全是多余的。

当然，自然连接同样支持左外连接和右外连接。

下面用一个 customers 表自连接的例子再来说明一下自然连接，语句如下：

因为是自连接，因此必须使用 AS 指定别名，否则 MySQL 无法区分“两个” customers 表，运行的结果如下：

可以看到结果集和 customers 表完全一致，大家可以思考一下为什么结果是这样的。

文章之前也提到了，MySQL 还支持一种 SQL 标准中没有定义的“方言”， STRAIGHT_JOIN ， STRAIGHT_JOIN 支持带 ON 子句的内连接和不带 ON 子句的交叉连接，我们来看一个 STRAIGHT_JOIN 版本的内连接的例子：

返回结果与前面内连接的例子是一致的，如下：

STRAIGHT_JOIN 的表现和 JOIN 是完全一致的，它只是一种给 MySQL 优化器的提示，使得 MySQL 始终按照语句中表的顺序读取表（上面的例子中，MySQL 在执行时一定会先读取 customers 表，再读取 orders 表），而不会做改变读取表的顺序的优化。关于 MySQL 优化器的话题这里不做展开，需要说明的是除非你非常清楚你在做什么，否则不推荐直接使用 STRAIGHT_JOIN 。

你能理解上面的语句是在检索什么数据吗？

本文主要介绍了 SQL 标准里定义的各种连接的概念，以及 MySQL 中的实现，并通过各种例子来介绍了这些连接的区别。这些连接不一定都能在实际开发中用到，但是做到心中有知识也还是很有必要的。

那么，现在再回忆一下，什么是内连接、外连接、自连接、等值连接和自然连接？他们的区别是什么？

最后，给大家留一个思考题，为什么 MySQL 中没有左外连接或者右外连接版本的 STRAIGHT_JOIN ？

常听说MySQL中3表 join 的执行流程并不是前两张表 join 得出结果，再与第三张表进行 join；而是3表嵌套的循环连接。那这个3表嵌套的循环连接具体又是个什么流程呢？与前两张表 join 得出结果再与第三张表进行 join 的执行效率相比如何呢？下面通过一个例子来分析分析。

set optimizer_switch='block_nested_loop=off'

关联字段无索引的情况下强制使用索引嵌套循环连接算法，目的是更好的观察扫描行数。

表结构和数据如下：

示例SQL：

通过 slow log 得知一共扫描 24100 行：

执行计划显示用的索引嵌套循环连接算法：

扫描行数构成：

总行数=100+4000+20000=24100。

从这个结果来看，join 过程像是先 t1 和 t3 join 得出 20 行中间结果，再与 t2 进行 join 得出结果。这结论与我们通常认为的 3表 join 实际上是3表嵌套的循环连接不一样，接着往下看。

查看执行计划成本：

mysql>explain format=json select * from t1 join t2 on t1.b=t2.b join t3 on t1.b=t3.b where t1.a<21\G

其他信息：

IO成本= 1*1.0 =1

CPU成本= 100*0.2 =20

t1总成本=21

IO成本= 1*1.0 =1

CPU成本= 200*0.2 =40

t3表总成本= 驱动表扇出*(IO成本+CPU成本) = 20*(1+40) =820

阶段性总成本= 21+820 =841

此处 eval_cost=80，实则为 驱动表扇出*被驱动每次扫描行数*filtered*成本常数 ，即 20*200*10%*0.2 。

简化公式为： eval_cost=rows_produced_per_json*成本常数

IO成本= 4*1.0 =4

CPU成本= 1000*0.2 =200

t2表总成本= 前2表join的扇出*(IO成本+CPU成本) = 400*(4+200) =81600

阶段性总成本= 841+81600 =82441

此处 eval_cost=8000，即 rows_produced_per_json*成本常数 ，即 40000*0.2

根据执行计划成本分析：

这样看，3表 join 流程是：

注意，由于造的数据比较特殊，所以第 3 步得出的中间结果集实际上只有 1行，所以最终 t2 表的查找次数是 20*1=20 ，所以扫描总行数是 20*1000 。所以单看 slow log 中显示的 24100 行，会误认为是先得出 t1 和 t3 join 的结果，再去和 t2 进行 join。

当我调整 t3 的数据，删除20行，再插入20行，使满足 b<21 的数据翻倍，这样“第 3 步得出的中间结果集”变成 2 行：

再来看slow log 中扫描的总行数为44100，t1、t3的扫描行数不变，t2 的扫描行数变为 20*2*1000=40000 ：

为什么执行计划中分析得到的是 t2 表查找 400 次呢？

因为执行计划对t1 join t3 的扇出是个估算值，不准确。而 slow log 是真实执行后统计的，是个准确值。

为什么执行计划中，t2表的执行次数是用“t1 join t3 的扇出”表示的？这不是说明 t1 先和 t3 join，结果再和 t2 join？

其实拆解来看，“3表嵌套循环” 和 “前2表 join 的结果和第3张表 join” 两种算法，成本是一样的，而且如果要按3表嵌套循环的方式展示每张表的成本将非常复杂，可读性不强。所以执行计划中这么表示没有问题。

总的来说，对于3表join或者多表join 来说，“3表嵌套循环” 和 “先2表 join，结果和第3张表join” 两种算法，成本是一样的。要注意的一点是3表嵌套循环成本并非如下图写的：n m x，而是 n (m+a x)，其中 a 为 t2 满足单个等值条件的平均值。

当被驱动表的关联字段不是唯一索引，或者没有索引，每次扫描行数会大于1时，其扇出误差会非常大。比如在上面的示例中：

t3 实际的扇出只有 20，但优化器估算值是 总扫描行数的 10%，由于t3表的关联字段没有索引，所以每次都要全表扫描200行，总的扫描行数= 20*200 =4000，扇出= 4000*10% =400，比实际的20大了20倍。尤其对于后续表的 join 来说，成本估算会产生更严重的偏差。

如果是 left join，每个被驱动表的 filtered 都会被优化器认定为 100%，误差更大！

通常建议join不超过2表，就是因为优化器估算成本误差大导致选择不好的执行计划，如果要用，一定要记住：关联字段必须要有索引，最好有唯一性或者基数大。

你应该这样：

select  GROUP_CONCAT(stu.name),sum(scores.score) from scores join stu on scores.name_id=stu.id

Mysq可不会智能到自动揣摩你的心思把其他字段合并起来。

另外，上述用法也只能在Mysql中有效，其他数据库中是要出错的，因为按照SQL标准，含有聚合函数的查询语句只能包含聚合字段以及GROUP by后面定义的字段，不能包含其他字段的，所以Mysql实际上属于犯规了

---