服务器之家:专注于服务器技术及软件下载分享
分类导航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|数据库技术|

服务器之家 - 数据库 - 数据库技术 - SQL 不知道咋优化?吹一手 Join 语句的优化准没错

SQL 不知道咋优化?吹一手 Join 语句的优化准没错

2022-01-11 23:21飞天小牛肉小牛肉 数据库技术

面试最怕遇到的问题是什么,如何做优化一定当仁不让,SQL 优化更是首当其冲,这里先跟大家分享一个比较容易理解的 join 语句的优化~

SQL 不知道咋优化?吹一手 Join 语句的优化准没错

本文转载自微信公众号「飞天小牛肉」,作者小牛肉 。转载本文请联系飞天小牛肉公众号。

面试最怕遇到的问题是什么,如何做优化一定当仁不让,SQL 优化更是首当其冲,这里先跟大家分享一个比较容易理解的 join 语句的优化~

前文提到过,当能够用上被驱动表的索引的时候,使用的是 Index Nested-Loop Join 算法,这时性能还是很好的;但是,用不上被驱动表的索引的时候,使用的 Block Nested-Loop Join 算法性能就差多了,非常消耗资源。

针对 join 语句的这两种情况,其实都还是存在继续优化的空间的

老规矩,背诵版在文末。点击阅读原文可以直达我收录整理的各大厂面试真题

Multi-Range Read 优化

我们先来回顾一下 “回表” 这个概念。回表是指,InnoDB 在普通索引上查到主键 id 的值后,再根据主键 id 的值到主键索引树上去查询整行记录的过程。

那么,思考一个问题,回表的过程是一行行地查数据,还是批量地查数据?

显然是一行行地。

因为回表查询的本质就是查询 B+ 树,在这棵树上,每次只能根据一个主键 id 查到一行数据。

看下面这条语句,从 user 表中获取 80 岁以上用户的信息:

  1. select * from user where age >= 80;

假设,age 对应的 id 是连续自增的,这样,我们对于主键索引树的查询,就是连续的:

SQL 不知道咋优化?吹一手 Join 语句的优化准没错

当然,这是理想情况,如果 age 对应的 id 值不是顺序的话,那当我们顺序取 age 的时候,id 的获取就是乱序随机的了,性能就会比较差。解释下为什么这里乱序查询的性能就比较差:

首先,我们都知道,索引文件其实就是一个磁盘文件,尽管有内存中 Buffer Pool 的存在可以减少访问磁盘的次数,但是并不能完全避开对磁盘的访问。而对于磁盘来说,一个磁盘从内到外有许多磁道,一个磁道又被划分成多个相同的扇区,随机读取性能较差的原因就是每次都需要花费时间去寻找磁道,找到磁道之后又要去寻找合适的扇区,从而耗费大量时间。所以顺序读取比随机读取快很多。

SQL 不知道咋优化?吹一手 Join 语句的优化准没错

所以,一个很自然的想法,就是调整主键 id 查询的顺序,使其接近顺序读取,从而达到加速的目的。

那么,具体该如何调整主键 id 查询的顺序呢?

因为大多数的数据都是按照主键 id 递增顺序插入的,对吧,所以我们可以简单的认为,如果按照主键 id 的递增顺序查询的话,对磁盘的读取会比较接近顺序读取,从而提升读性能。这就是 Multi-Range Read (MRR) 优化的思想。

而将主键 id 进行升序排序的过程,是在内存中的随机读取缓冲区 read_rnd_buffer 中进行的。

我们可以设置 set optimizer_switch="mrr_cost_based=off" 来开启 MRR 优化,这样,语句的执行流程就是下面这个样子:

  • 根据普通索引 age,找到满足条件的主键 id,然后将 id 值放入 read_rnd_buffer 中
  • 将 read_rnd_buffer 中的 id 进行递增排序;
  • 根据排序后的 id 数组,进行回表查询

SQL 不知道咋优化?吹一手 Join 语句的优化准没错

需要注意的是,read_rnd_buffer 的大小是由 read_rnd_buffer_size 参数控制的。如果发现 read_rnd_buffer 放满了,那么 MySQL 就会先执行完步骤 2 和 3,然后清空 read_rnd_buffer,之后再继续循环。

可以看出来,使用 MRR 提升性能主要适用于范围查询,这样可以得到足够多的主键 id,通过排序以后,再去主键索引查数据,从而体现出顺序读取的优势。

MRR 这种开辟一个内存空间对主键 id 进行排序的思想呢,应用到 join 语句的优化层面上来,就是 MySQL 在 5.6 版本后引入的 Batched Key Access 算法(BKA),下面我们来解析下这个算法以及如何使用这个算法对 Index Nested-Loop Join 和 Block Nested-Loop Join 两种情况进行优化。

优化 Index Nested-Loop Join

假设我们已经在 age 字段上建立了索引,那么下面这条 sql 语句用到的就是 Index Nested-Loop Join 算法,回顾下具体的执行逻辑:

  1. select * from table1 join table2 on table1.age = table2.age where table2.age >= 80;

从 table1 表中读入一行数据 R

从数据行 R 中,取出 age 字段到表 table2 的 age 索引树上去找并取得对应的主键

根据主键回表查询,取出 table2 表中满足条件的行,然后跟 R 组成一行,作为结果集的一部分

也就是说,对于表 table2 来说,每次都是只匹配一个值。这时,MRR 的优势就用不上了。

所以,如果想要享受到 MRR 带来的优化,就必须在被驱动表 table2 上使用范围匹配,换句话说,我们需要一次性地多传些值给表 table2。那么具体该怎么做呢?

方法就是,从表 table1 中一次性地多拿些行出来,先放到一个临时内存中,然后再一起传给表 table2。而这个临时内存不是别人,就是 join_buffer!

之前我们分析过 Block Nested-Loop Join 算法中用到了 join_buffer,而 Index Nested-Loop Join 并没有用到,这不,在优化这里派上用场了。

这就是 BKA 算法对 Index Nested-Loop Join 的优化,可以通过下面这行命令启用 BKA 优化算法

  1. set optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';

前两个参数的作用是启用 MRR,因为 BKA 算法的优化依赖于 MRR。

优化 Block Nested-Loop Join

那如果用不上被驱动表索引的话,使用的 BNL 算法性能是比较低的,所以常见的优化方法就是给被驱动表的 join 字段加上索引。

但是,如果这条 SQL 语句的使用频率比较低并且数据量不大的话,建立索引其实就比较浪费资源了。

所以,有没有一种两全其美的办法呢?

这时候,我们可以考虑使用临时表。使用临时表的大致思路是:

把表 table2 中满足条件的数据放在临时表 temp_table2 中

给临时表 temp_table2 的字段 age 加上索引

让表 table1 和 temp_table2 做 join 操作

这样,一个 BNL 算法的优化问题,就被我们转换成了 Index-Nested Loop Join 的优化问题了,按照上述所说的,可以使用 BKA 进行优化。

具体的 SQL 语句如下:

  1. # select * from table1 join table2 on table1.age = table2.age where table2.age >= 80;
  2. create temporary table temp_table2 (id int primary key, name varchar, age int, index(age)) engine=innodb;
  3. insert into temp_table2 select * from table1 where age >= 80;
  4. select * from table1 join temp_table2 on (table1.b=temp_table2 .b);

总的来说,优化 Block Nested-Loop Join 的思路就是使用有索引的临时表,让 join 语句能够用上被驱动表上的索引,从而转换为 Index Nested-Loop Join 然后触发 BKA 算法,提升查询性能。

最后放上这道题的背诵版:

面试官:SQL 优化了解过吗?

小牛肉:先说 join 语句的优化

join 语句分为两种情况,一种是能够用上被驱动表的索引,这个时候使用的算法是 Index Nested-Loop,另一种是用不上,这个时候使用的算法是 Block Nested-Loop

  • 对于 Index Nested-Loop 来说,具体步骤其实就是一个嵌套查询,首先,遍历驱动表,然后,对这每一行都去被驱动表中根据 on 条件字段进行搜索,由于被驱动表上建立了条件字段的索引,所以每次搜索只需要在辅助索引树上扫描一行就行了,性能比较高
  • 对于 Block Nested-Loop 来说,MySQL 首先把驱动表中的数据读入线程内存 join_buffer 中;然后扫描被驱动表,把被驱动表中的每一行依次取出来,跟 join_buffer 中的数据做对比,满足 on 条件的,就作为结果集的一部分返回。BNL 算法的性能比较差,因为我们需要多次遍历被驱动表。那么对于 BNL 算法来说,一个很常见的优化思路就是对被驱动表的条件字段建立索引,从而转换成 Index Nested-Loop 算法。

对于上面这两种 join 情况来说,如果继续添加一个范围查询的 where 条件的话,其实还存在优化空间。

其核心做法其实就是针对范围查询的优化,也称为 Multi-Range Read 算法

具体来说,因为大多数的数据都是按照主键 id 递增顺序插入的嘛,所以我们可以简单的认为,如果按照主键 id 的递增顺序进行查询的话,对磁盘的读取会比较接近顺序读取,这样相比于乱序读取的话减少了寻道时间,从而提升读性能。

而将主键 id 进行升序排序的过程,是在内存中的随机读取缓冲区 read_rnd_buffer 中进行的。就是先把在辅助索引树上查找的满足条件的主键 id 存到 read_rnd_buffer 中,然后对这些 id 进行递增排序,根据排序后的 id 数组,进行回表查询。

MRR 的思想应用到 join 语句的优化层面上来,就是 MySQL 在 5.6 版本后引入的 Batched Key Access,BKA 算法

  • 对于 Index Nested-Loop 来说,就是一次性地从驱动表中取出很多个行记录出来,先放到临时内存 join_buffer 中,然后再一起传给被驱动表
  • 对于 Block Nested-Loop 来说,就是对被驱动表建立一个临时表,并且对条件字段建立索引,然后把之前两张表的 join 操作转换成驱动表和临时表的 join 操作,从而转换成对 Index Nested-Loop 的优化问题

balabala.......(后续其他 SQL 优化会慢慢更新的~)

原文链接:https://mp.weixin.qq.com/s/BmdVXyVyiT530TwYwWt5_g

延伸 · 阅读

精彩推荐