SQL 不知道咋优化?吹一手 Join 语句的优化准没错
  • 首页
  • 产品展示
  • 关于品牌
  • 栏目分类
    产品展示你的位置:辽源市坤达泡沫制品加工有限公司 > 产品展示 > SQL 不知道咋优化?吹一手 Join 语句的优化准没错

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

    发布日期:2022-08-07 12:06    点击次数:181

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

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

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

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

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

    Multi-Range Read 优化

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

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

    显然是一行行地。

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

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

    select * from user where age >= 80; 

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

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

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

    所以,一个很自然的想法,就是调整主键 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 数组,进行回表查询

    需要注意的是,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 算法,回顾下具体的执行逻辑:

    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 优化算法

    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 语句如下:

    # select * from table1 join table2 on table1.age = table2.age where table2.age >= 80; create temporary table temp_table2 (id int primary key, name varchar, age int, index(age)) engine=innodb; insert into temp_table2  select * from table1 where age >= 80; 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 优化会慢慢更新的~)

     



    Powered by 辽源市坤达泡沫制品加工有限公司 @2013-2022 RSS地图 HTML地图

    Copyright 站群 © 2013-2022 365建站器 版权所有