MySQL中的Join连接查询

Blue Protocol

已于 2023-03-04 12:52:33 修改

阅读量2.4k

点赞数 2

分类专栏： MySQL 文章标签： MySQL 连表查询 JOIN 笛卡尔积 Join算法

于 2023-03-04 02:02:55 首次发布

本文链接：https://blog.csdn.net/weixin_51921447/article/details/129316176

版权

MySQL 专栏收录该内容

13 篇文章 1 订阅

订阅专栏

文章介绍了数据库查询中的Join操作，包括Join的分类如内联接、左联接和右联接，以及为何不推荐出现笛卡尔积，因为它在大数据量时会导致性能问题。小表驱动大表是优化查询的一个策略，通过减少连接次数提高查询效率。此外，文章还讨论了NLJ和BNLJ两种连接算法，并提出了编写高性能连接查询的建议。最后，提到MySQL不推荐大量使用Join主要是性能考虑，并提出单表查询作为替代方案。

摘要由CSDN通过智能技术生成

Join

首先我们先抛出一个问题，为什么要使用Join?
Join可以将我们数据库中的两张或者两张以上的表进行连接操作，并且使用Join做关联查询的好处是可以做分页。

Join的分类

Join的分类我们可以具体看下面这张图片。

在这里插入图片描述

具体分类说明看下文。

笛卡尔积

笛卡尔积是我们多表联合查询的时候会出现的一种现象。我们来举个例子来简单理解笛卡尔积。
假设集合A={a, b}有两个元素，集合B={0, 1, 2}有三个元素，则两个集合的笛卡尔积为
{(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}，有2*3为6个元素。

笛卡尔积出现的原因

如果数据库表关联查询时，只是纯粹的进行表连接没有使用其他条件，会出现全部的笛卡尔积。
数据库表关联查询，如果ON条件是非唯一字段，则会出现局部笛卡尔积。
数据库表关联查询，如果ON条件是表的唯一字段，则不会出现笛卡尔积。

为什么不推荐有笛卡尔积出现

笛卡尔积没有什么实践意义。在实际应用中，笛卡尔积本身大多没有什么实际用处，只有在两个表连接时加上限制条件，才会有实际意义。
多个大数据量的表产生的笛卡尔积表会占用很大的内存空间。

那应该怎么做多表连接

我们在进行表连接查询的时候一般都会使用JOIN xxx ON xxx的语法，ON语句的执行是在JOIN语句之前的，也就是说两张表数据行之间进行匹配的时候，会先判断数据行是否符合ON语句后面的条件，再决定是否JOIN。

（因此，有一个显而易见的SQL优化的方案是，当两张表的数据量比较大，又需要连接查询时，应该使用 FROM table1 JOIN table2 ON xxx的语法，避免使用 FROM table1,table2 WHERE xxx 的语法，因为后者会在内存中先生成一张数据量比较大的笛卡尔积表，增加了内存的开销。）

Join的使用

Join的分类

内联接（Inner Join）：内连接查询返回满足条件的所有记录，如果没有指定是left还是right 仅仅只有一个join也是inner join。
左联接（Left Join）：除了匹配2张表中相关联的记录外，还会匹配左表中剩余的记录，右表中未匹配到的字段用NULL表示。
右外联接（Right Join）：除了匹配2张表中相关联的记录外，还会匹配右表中剩余的记录，左表中未匹配到的字段用NULL表示。

小表驱动大表

说到连接，我们经常会听到的规则是小表驱动大表。

小表驱动大表是什么

小表驱动大表指的是用小数据集的来驱动大数据集。

小表驱动大表的好处

我们可以使用两个循环来理解小表驱动大表，例如：现有两个表A与B ，表A有200条数据，表B有20万条数据
小表驱动大表： A驱动表，B被驱动表

 for(200条){
     for(20万条){
       ...
     }
 }

大表驱动小表： B驱动表，A被驱动表

 for(20万){
      for(200条){
       ...
      }
 }

看以上两个for循环，总共循环的次数是一样的。但是对于MySQL数据库而言，并不是这样了，我们尽量选择第1个for循环，也就是小表驱动大表。
数据库连接的建立，第一个建立了200条次链接，第二个建立了20万次链接。假设链接了两次，每次做上百万次的数据集查询，查完就走，这样就只做了两次；相反建立了上百万次链接，申请链接释放反复重复，这样系统就受不了了。

综上，小表驱动大表的好处是

通过减少创建连接的次数，来加快查询速度。
驱动表索引没有生效，被驱动表索引有效。检索大表的时候可以使用索引，B+树查找时间复杂度是logn，所以小驱大大概的时间200log2000000，当然比2000000log200快很多

如何区分哪一个是驱动表和被驱动表

1）通过EXPLAIN查看SQL语句的执行计划可以判断在谁是驱动表，EXPLAIN语句分析出来的第一行的表即是驱动表 ;
2）在JOIN查询中经常用到的 inner join、left join、right join
（1）当使用left join时，左表是驱动表，右表是被驱动表 ;
（2）当使用right join时，右表时驱动表，左表是被驱动表 ;
（3）当使用inner join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表 ;

测试环境配置：MYSQL 5.7
数据准备：创建两张测试表 大表 user_big_info ，测试数据400万条, 小表user_small_info ,测试数据200万条 ;

CREATE TABLE `user_small_info` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `user_id` varchar(32) NOT NULL COMMENT '用户唯一标识',
  `username` varchar(32) NOT NULL DEFAULT '' COMMENT '用户名',
  `password` varchar(255) NOT NULL DEFAULT '' COMMENT '密码',
  `real_name` varchar(32) NOT NULL DEFAULT '' COMMENT '真实姓名',
  `phone` varchar(32) NOT NULL DEFAULT '' COMMENT '手机号码',
  `remarks` varchar(255) NOT NULL DEFAULT '' COMMENT '备注',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态 1-启用 2-禁用 ',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_user_id` (`user_id`) USING BTREE,
  KEY `idx_username` (`username`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3000001 DEFAULT CHARSET=utf8 COMMENT='用户表';

LEFT JOIN 测试：小表驱动大表

在这里插入图片描述

结果：

在这里插入图片描述

执行时间：18.141s ，由于使用左连接以小表为主表所以，返回行数:200万。
执行计划

LEFT JOIN 测试：大表驱动小表

在这里插入图片描述

在这里插入图片描述

执行时间：25.949s ，由于使用左连接以大表为主表所以，返回行数: 400万
执行计划

Join原理及算法

我们在进行表连接查询的时候一般都会使用JOIN xxx ON xxx的语法，ON语句的执行是在JOIN语句之前的，也就是说两张表数据行之间进行匹配的时候，会先判断数据行是否符合ON语句后面的条件，再决定是否JOIN,对参与 Join 操作的基表或视图进行过滤，之后再对两表进行 Join 操作，输出结果集。

在这里插入图片描述

对于三表或多表 Join，则都是可以拆分为两表 Join 的方式进行处理，最先参与 Join 操作的两个表的 Join 的结果集，以表的形式参与后续的 Join 操作。

在这里插入图片描述

NLJ算法

NLJ：Nested-Loop Join（嵌套循环算法）
执行过程：一次一行地从驱动表中读取行，在这行数据中取到关联字段，根据关联字段在被驱动表里取出满足条件的行，然后取出两张表的结果合集。

 EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

在这里插入图片描述

如果被驱动表中关联字段存在索引，整个过程会读取驱动表中所有的数据（比如100行），然后遍历每行数据中字段a的值，然后在遍历出来的a值索引扫描被驱动表中的对应行，一次找到一个，整个过程扫描了200行。

BNLJ算法

BNLJ：Block Nested-Loop Join（基于块的嵌套循环连接）
执行过程：把驱动表的数据全部读入join_buffer中，然后扫描被驱动表，把被驱动表的每一行取出来和join_buffer中的数据做对比，重复这个步骤。这个过程做了两次全表扫描ALL。

EXPLAIN select * from t1 inner join t2 on t1.b= t2.b;

在这里插入图片描述

整个过程对驱动表和被驱动表都做了一次全表扫描（比如t1=10000,t2=100），扫描总行数：10000+100=10100，并且join_buffer里面的数据是无序的，因此对被驱动表的每一行，都需要,100次判断，所以内存中的判断次数是10000*100=100w次。

问题1：join buffer一次性放不下t2表怎么办？
join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。如果放不下表 t2 的所有数据话，策略很简单，就是分段放。
举栗子：比如 t2 表有1000行记录， join_buffer 一次只能放800行数据，那么执行过程就是先往 join_buffer 里放800行记录，然后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空 join_buffer ，再放入 t2 表剩余200行记录，再次从 t1 表里取数据跟 join_buffer 中数据对比。所以就多扫了一次 t1 表。

问题2：被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢？

如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有索引的情况下 NLJ 算法比 BNL算法性能更高。

总结：如何写入高性能的连接查询

连表的时候，我们需要去关注磁盘的IO。一般的操作是用小表驱动大表，注意在连接字段上建立索引，特别是被驱动表，这样MySQL内部使用的就是NLJ算法进行连接处理，能有效减少磁盘IO。如果连接条件有索引，MySQL内部会使用NLJ算法。如果没有索引，MySQL内部会使用BNLJ算法来基于内存计算，减少磁盘的IO扫描。