详解MySQL数据库的Index Condition Pushdown(ICP)特性

网友投稿 893 2023-05-11

详解MySQL数据库的Index Condition Pushdown(ICP)特性

详解MySQL数据库的Index Condition Pushdown(ICP)特性

概述

今天主要介绍一下mysql的ICP特性,可能很多人都没听过,这里用一个实验来帮助大家加深一下理解。

一、Index_Condition_Pushdown

Index Condition Pushdown (ICP)是MySQL用索引去表里取数据的一种优化。如果禁用ICP,引擎层会穿过索引在基表中寻找数据行,然后返回给MySQL Server层,再去为这些数据行进行WHERE后的条件的过滤。

ICP启用,如果部分WHERE条件能使用索引中的字段,My*** 会把这部分下推到引擎层。存储引擎通过使用索引条目,然后推索引条件进行评估,使用这个索引把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。总之是 ICP的优化在引擎层就能够过滤掉大量的数据,这样无疑能够减少了对base table和mysql server的访问次数。

ICP的优化用于range, ref, eq_ref, and ref_or_null访问方法,当这些需要访问全表的行。这个策略可以用于INNODB和MyISAM表。

二、实验

先从一个简单的实验开始直观认识ICP的作用。

1、导入示例数据

这里使用Employees Sample Database,作为示例数据库。

将下载的压缩包解压后,会看到一系列的文件,其中employees.sql就是导入数据的命令文件。执行

#yum -y install bzip2 #tar -xvf employees_db-full-1.0.6.tar.bz2 #mysql -uroot -p

就可以完成建库、建表和load数据等一系列操作。此时数据库中会多一个叫做employees的数据库。库中的表如下:

mysql > SHOW TABLES;

下面将使用employees表做实验。

2、建立联合索引

employees表包含雇员的基本信息,表结构如下:

mysql > DESC employees.employees;

这个表默认只有一个主索引,因为ICP只能作用于二级索引,所以我们建立一个二级索引:

ALTER TABLE employees.employees ADD INDEX first_name_last_name (first_name, last_name);

这样就建立了一个first_name和last_name的联合索引。

3、查询(ICP启用)

为了明确看到查询性能,启用profiling并关闭query cache:

SET profiling = 1; SET query_cache_type = 0; SET GLOBAL query_cache_size = 0;

然后看下面这个查询:

mysql > SELECT * FROM employees WHERE first_name='Mary' AND last_name LIKE '%man';

根据MySQL索引的前缀匹配原则,两者对索引的使用是一致的,即只有first_name采用索引,last_name由于使用了模糊前缀,没法使用索引进行匹配。我将查询联系执行三次,结果如下:

mysql> show profiles;

查看执行计划

mysql> explain SELECT * FROM employees WHERE first_name='Mary' AND last_name LIKE '%man';

4、查询(ICP禁用)

关闭ICP:

SET optimizer_switch='index_condition_pushdown=off';

在运行三次相同的查询,结果如下:

有意思的事情发生了,关闭ICP后,同样的查询,耗时是之前的三倍以上。

下面我们用explain看看后者的执行计划:

mysql> explain SELECT * FROM employees WHERE first_name='Mary' AND last_name LIKE '%man';

从开启ICP和关闭ICP的执行计划可以看到区别在于Extra,开启ICP时,用的是Using index condition;关闭ICP时,是Using where。

其中Using index condition就是ICP提高查询性能的关键。下面说明ICP提高查询性能的原理。

三、原理

ICP的原理简单说来就是将可以利用索引筛选的where条件在存储引擎一侧进行筛选,而不是将所有index access的结果取出放在server端进行where筛选。

以上面的查询为例,在没有ICP时,首先通过索引前缀从存储引擎中读出224条first_name为Mary的记录,然后在server段用where筛选last_name的like条件;而启用ICP后,由于last_name的like筛选可以通过索引字段进行,那么存储引擎内部通过索引与where条件的对比来筛选掉不符合where条件的记录,这个过程不需要读出整条记录,同时只返回给server筛选后的6条记录,因此提高了查询性能。

1) 不使用ICP时,如何进行索引扫描

(1)当storage engine读取下一行时,首先读取索引元组(index tuple),然后使用索引元组在基表中(base table)定位和读取整行数据。

(2) sever层评估where条件,如果该行数据满足where条件则使用,否则丢弃。

(3)执行第1步,直到最后一行数据。

2)使用ICP时,如何进行索引扫描

(1)storage engine从索引中读取下一条索引元组。

(2) storage engine使用索引元组评估下推的索引条件。如果没有满足where条件,storage engine将会处理下一条索引元组(回到上一步)。只有当索引元组满足下推的索引条件的时候,才会继续去基表中读取数据。

(3)如果满足下推的索引条件,storage engine通过索引元组定位基表的行和读取整行数据并返回给server层。

(4)server层评估没有被下推到storage engine层的where条件,如果该行数据满足where条件则使用,否则丢弃。

用两张图来做说明:

关闭ICP

在不支持ICP的系统下,索引仅仅作为data access使用。

开启ICP

在ICP优化开启时,在存储引擎端首先用索引过滤可以过滤的where条件,然后再用索引做data access,被index condition过滤掉的数据不必读取,也不会返回server端。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:一文聊聊 Redis 的缓存场景
下一篇:分布式Redis深度历险-Sentinel
相关文章