什么是索引下推
首先,我们创建一张user
表,同时建立age_name
的联合索引,同时插入3条测试数据。
然后,我们执行查询explain SELECT * from user where age >10 and name = 'a'
,如下图所示,就会看见Extra
中显示了Using index condition
,你可能就知道了,这表示出现了索引下推了。
没错,针对这个查询场景就是索引下推,那到底什么是索引下推呢?
按照我们上述的场景,实际上就存在两个索引树,一个是主键索引,存储了具体的数据的信息,另外则是age_name
的联合索引,保存了主键的ID。
在没有ICP索引下推的时候,这个查询的流程应该是这样(略过无关的细节):
- Mysql Server层调用API查询存储引擎数据
- 存储引擎根据联合索引首先通过条件找到所有age>10的数据
- 找到的每一条数据都根据主键索引进行回表查询,直到找到不符合条件的结果
- 返回数据给Server层,Server根据条件对结果进行过滤,流程结束
而有了ICP之后的流程则是这样:
- Mysql Server层调用API查询存储引擎数据
- 存储引擎根据联合索引首先通过条件找到所有age>10的数据,根据联合索引中已经存在的
name
数据进行过滤,找到符合条件的数据 - 根据找到符合条件的数据,回表查询
- 返回数据给Server层,流程结束
对比这两个流程就会很明显的发现,使用ICP之后我们就是简单的通过联合索引中本来就有的数据直接过滤了,不需要再查到一堆无用的数据去Server层进行过滤,这样的话减少了回表的次数和返回的数据,IO次数减少了,对性能有很好的提升。
按照官方文档所说,ICP其实也存在一定的使用限制场景,只说关键的,乱七八糟的不说。
- 首先,ICP适用于range、ref、eq_ref和ref_or_null的场景下
- InnoDB和MyISAM都支持ICP,Mysql partition分表的话也可以使用
- 对于InndoDB而言,ICP只支持二级索引,因为主键索引它用不上不是吗?
- 子查询不支持
现在我们基本都使用的5.6以上的版本了,默认就是开启ICP的,想关闭的话可以通过命令SET optimizer_switch = 'index_condition_pushdown=off';
。
一个小小的误区
一般来说,正常情况下Mysql一次查询都只能走一个索引,我们来修改上述的表结构,把联合索引改为两个单独的索引,数据保持不变
然后我们执行查询explain SELECT * from user where age >10 and name like 'a%'
,结果如下图。
你会发现,我靠,怎么还有索引下推?这不科学对不对,好像无法解释嘛,难道这一次索引下推还能先查出age
再下推到name
索引吗,这完全不合理啊。
其实不然,真实的情况是,Using index condition
并不代表一定是使用了索引下推,只是代表可以使用,但是不一定用了。。。
这个就有点坑爹,可能会对我们判断的时候造成误解啊。
如果你去网上搜很多人举例子这样建索引,然后告诉你这就是索引下推的时候,你可以尽情的喷他了,我们说索引下推一定是在联合索引的情况下,根据联合索引本身就有的数据直接做一次过滤,而不用再进行多次无用的回表再到Server层进行过滤,这一点你要很明确才行。
好了,今天的话题就到这里结束,我是艾小仙,我们下期见。
(本来我想多画两张图的,不过好像觉得这个概念实在太简单了,画的花里胡哨的反而没有意义,就像你说覆盖索引、回表还画好几张图给你解释吗,没有必要对不对,肯定不是因为我懒。。。)