MySQL 分页查询优化——延迟关联优化

目录

1.   InnoDB表的索引的几个概念

2.   覆盖索引和回表

3.   分页查询

4.   延迟关联优化

写在前面

下面的介绍均是在选用MySQL数据库和Innodb引擎的基础开展。我们先来学习索引的几个概念,帮助我们理解延迟关联优化的加快分页查询速度的原因。

一、Innodb表的索引的几个概念

InnoDB表是基于聚簇索引建立的。

索引一般分为主键索引和普通索引(辅助索引),聚簇索引并不是主键索引这样的单独的索引类型,而是一种数据存储方式。通俗的来说,单独的索引是存储了索引信息的B+Tree,而聚簇索引是在同一个结构中保存了B+Tree和数据行,即通过主键索引B+Tree的结构建立数据文件(网上的说法是索引和数据存储在同一个文件中),因此聚簇索引是一种数据存储方式。

如果对于索引的概念不是很熟悉,建议去查阅相关资料学习,索引是一个很庞大的知识结构。

 

Innodb表以主键索引建立后缀名为.MYD表存储文件,普通索引亦以B+Tree实现,并保存在后缀名为.MYI的文件中,具体结构图如下所示:


 

在查询时选用主键索引和普通索引有什么不一样呢?

以下面语句为例:

·       select * from table where id = 5;id为主键索引) 检索过程如上图绿色箭头所示,直接在主索引树上根据主键检索

·       select * from table where name = "Gates"; name为普通索引)检索过程如上图红色箭头所示,先根据普通索引检索普通索引树得到id5,然后再拿得到的id到主索引树检索得到结果。在这个过程中,回到主键索引树搜索的过程,我们称为回表。

 

从这里可以看出,基于非主键索引的查询需要多扫描一棵索引树。因此,我们在应用中应该尽量使用主键查询。

解释完普通索引和主键索引的检索过程,让我们来看看什么是覆盖索引。

二、覆盖索引和回表。

什么是覆盖索引

查询的列被所建的辅助索引所覆盖,无需回表。用大白话解释就是,要查的数据直接可以从索引树上就能取得,无需回表查找。

注意:不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引的列,而哈希索引、空间索引和全文索引等都不存储索引列的值,所以MySQL只能使用B-Tree索引做覆盖索引

结合上图的例子:

·       select id from table where name = "Gates"; 即为一个覆盖索引。

 

三、分页查询使用场景

需求:查询最近 7 天的订单,并做分页。订单表数据量:3000W

未经优化的SQL

select * from t_trade_order

where create_time between '2019-10-17' and '2019-10-25'

limit 1000000, 10;

 

根据explain输出的结果可知,这是一条慢查询,在业务环境中不允许出现这样的慢查询。

 

我们都知道在做分页时会用到Limit关键字去筛选所需数据,limit接受1个或者2个参数,接受两个参数时第一个参数表示偏移量,即从哪一行开始取数据,第二个参数表示要取的行数。 如果只有一个参数,相当于偏移量为0。当偏移量很大时,如limit 100000,10 取第100001-100010条记录,mysql会取出100010条记录然后将前100000条记录丢弃,这无疑是一种巨大的性能浪费。

 

终于转入正题了,那我们应该怎样优化呢?

 

四、延迟关联优化

《高性能MySQL》书中其实也讨论这个情况:

延迟关联优化:通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据。

 

select * from t_trade_order t

inner join (

     select id from t_trade_order

    where create_time between '2019-10-17' and '2019-10-25'

     limit 1000000, 10

) e

on t.id = e.id;

 

根据explain分析,查询时间仅为0.31,比普通的分页查询快了一个数量级。

 

想必大家会想知道,为什么延迟关联对比普通分页查询可以起到这样的优化效果呢?

这就涉及到上面所讲的覆盖索引和回表这两个重要概念了!

 

我们来看看这两条语句的执行流程就很清楚了。

优化前:

select * from t_trade_order

where create_time between '2019-10-17' and '2019-10-25'

limit 1000000, 10;

create_time建表时被设置为普通索引)

 

1.create_time索引树上找到create_time=‘2019-10-17’的记录,取得其id

2.再到主索引树查到对于id的记录

3.如数量小于10,更新时间,循环步骤12

4. 。。。

5.create_time索引树取下一个值create_time='2019-10-25',不满足条件,循环结束。

6.查询结果放弃前1000000行,返回10

 

显然,普通的分页查询是逐一通过普通索引获得id然后回表查询,每次回表进行一次IO,造成相当大的性能浪费。

 

优化后

select * from t_trade_order t

inner join (

    select id from t_trade_order

   where create_time between '2019-10-17' and '2019-10-25'

    limit 1000000, 10

) e

on t.id = e.id;

 

1.使用覆盖索引,select id from t_trade_order where create_time between '2019-10-17' and '2019-10-25' limit 1000000, 10查询结果放弃前1000000行,返回10查询出符合查询范围的id

2、回表关联,根据获得的id关联主索引表,批量匹配得到结果。(只需回到主索引表一次)

 

由此可知,通过使用覆盖索引查询返回需要的主键,再根据这些主键关联原表获得需要的行,这可以减少MySQL回表的次数,也避免了MySQL直接在原表上扫描那些需要丢弃的行数(实则在普通索引树上扫描,速度快很多)。

 

文章写到这里,希望对大家理解延迟关联优化有些许帮助。

 

猜你喜欢

转载自www.cnblogs.com/pufeng/p/11750495.html