索引下推,这个点你肯定不知道!

索引下推(Index Condition Pushdown) ICP 是Mysql5.6之后新增的功能,主要的核心点就在于把数据筛选的过程放在了存储引擎层去处理,而不是像之前一样放到Server层去做过滤。

虽然这是一个比较简单的概念,但是可能很多不细心的同学对于索引下推会存在一个小小的误区,至于是什么,请看下文。

什么是索引下推

首先,我们创建一张user表,同时建立age_name的联合索引,同时插入3条测试数据。

image

然后,我们执行查询explain SELECT * from user where age >10 and name = 'a',如下图所示,就会看见Extra中显示了Using index condition,你可能就知道了,这表示出现了索引下推了。

image

没错,针对这个查询场景就是索引下推,那到底什么是索引下推呢?

按照我们上述的场景,实际上就存在两个索引树,一个是主键索引,存储了具体的数据的信息,另外则是age_name的联合索引,保存了主键的ID。

image

在没有ICP索引下推的时候,这个查询的流程应该是这样(略过无关的细节):

  1. Mysql Server层调用API查询存储引擎数据
  2. 存储引擎根据联合索引首先通过条件找到所有age>10的数据
  3. 找到的每一条数据都根据主键索引进行回表查询,直到找到不符合条件的结果
  4. 返回数据给Server层,Server根据条件对结果进行过滤,流程结束

而有了ICP之后的流程则是这样:

  1. Mysql Server层调用API查询存储引擎数据
  2. 存储引擎根据联合索引首先通过条件找到所有age>10的数据,根据联合索引中已经存在的name数据进行过滤,找到符合条件的数据
  3. 根据找到符合条件的数据,回表查询
  4. 返回数据给Server层,流程结束

对比这两个流程就会很明显的发现,使用ICP之后我们就是简单的通过联合索引中本来就有的数据直接过滤了,不需要再查到一堆无用的数据去Server层进行过滤,这样的话减少了回表的次数和返回的数据,IO次数减少了,对性能有很好的提升。

按照官方文档所说,ICP其实也存在一定的使用限制场景,只说关键的,乱七八糟的不说。

  1. 首先,ICP适用于range、ref、eq_ref和ref_or_null的场景下
  2. InnoDB和MyISAM都支持ICP,Mysql partition分表的话也可以使用
  3. 对于InndoDB而言,ICP只支持二级索引,因为主键索引它用不上不是吗?
  4. 子查询不支持

现在我们基本都使用的5.6以上的版本了,默认就是开启ICP的,想关闭的话可以通过命令SET optimizer_switch = 'index_condition_pushdown=off';

一个小小的误区

一般来说,正常情况下Mysql一次查询都只能走一个索引,我们来修改上述的表结构,把联合索引改为两个单独的索引,数据保持不变

image

然后我们执行查询explain SELECT * from user where age >10 and name like 'a%',结果如下图。

image

你会发现,我靠,怎么还有索引下推?这不科学对不对,好像无法解释嘛,难道这一次索引下推还能先查出age再下推到name索引吗,这完全不合理啊。

其实不然,真实的情况是,Using index condition并不代表一定是使用了索引下推,只是代表可以使用,但是不一定用了。。。

这个就有点坑爹,可能会对我们判断的时候造成误解啊。

如果你去网上搜很多人举例子这样建索引,然后告诉你这就是索引下推的时候,你可以尽情的喷他了,我们说索引下推一定是在联合索引的情况下,根据联合索引本身就有的数据直接做一次过滤,而不用再进行多次无用的回表再到Server层进行过滤,这一点你要很明确才行。

好了,今天的话题就到这里结束,我是艾小仙,我们下期见。

(本来我想多画两张图的,不过好像觉得这个概念实在太简单了,画的花里胡哨的反而没有意义,就像你说覆盖索引、回表还画好几张图给你解释吗,没有必要对不对,肯定不是因为我懒。。。)

你可能感兴趣的:(索引下推,这个点你肯定不知道!)