Index Condition Pushdown优化


1 概述
2 介绍
3 启用条件
4 优化过程

1 概述

Index Condition Pushdown(ICP)是MySQL在使用索引获取数据时的一种优化手段,使用ICP可以在使用索引获取数据时避免读取那些不符合查询条件的数据。本文主要翻译自MySQL官方文档对该优化的介绍

2 介绍

ICP主要用于在使用索引查询数据时进行优化。没有ICP优化时,存储引擎通过索引定位数据并读取这些被定位的数据返回给MySQL服务器,MySQL服务器会根据WHERE条件对这些数据进行过滤。当启用了ICP优化后,WHERE语句中那些仅仅使用优化器选中的索引列中的字段会被MySQL服务器推送给存储引擎,在存储引擎使用索引定位数据并根据索引中的字段进行WHERE条件过滤,然后在读取表中数据返回给MySQL服务器,MySQL服务器会对WHERE语句中剩下的条件进行过滤。有了ICP可以减少存储引擎访问表数据的次数,也减少了MySQL服务器访问存储引擎的次数。

3 启用条件

ICP优化必须满足如下条件:

  • ICP可以用于使用rangerefeq_refref_or_null访问方法时并需要访问表中所有行时。

  • ICP可以用于InnoDBMyISAM表,包括InnoDBMyISAM分区表。

  • 对于InnoDB,ICP只能用于二级索引。使用ICP的木器时为了减少完整表行的读取次数并较少IO操作,InnoDB一级索引(聚簇索引)已经包含了表行的所有列,并且已经位于InnoDB缓冲区内,使用ICP也就没有意义了。

  • InnoDB可以基于虚拟列建立二级索引,而ICP则不支持用于哪些建立在虚拟列上的二级索引。

  • 基于子查询的条件没法下放给存储引擎进行优化。

  • 基于函数的条件没法下放,因为存储引擎没法执行函数。

  • 触发器中的条件没法下放。

4 优化过程

为了理解ICP优化如何工作的,先看下没有ICP优化时的索引扫描过程:

  1. 读取下一行数据。首先读取索引数据,并根据索引数据定位读取完整的一行表数据返回给MySQL服务器;
  2. MySQL服务器根据WHERE语句中的条件对返回的数据进行测试,根据测试结果选择接受或放弃改行数据。

如果启用了ICP优化,则索引扫描过程如下:

  1. 读取下一个索引数据(不是完整的表行数据);
  2. 对于那些仅仅使用索引数据就可以进行测试的部分WHERE条件进行过滤,如果测试不通过则读取下一个索引数据;
  3. 如果测试通过,则根据此索引数据定位该行表数据并读取完整的一行表数据返回给MySQL服务器;
  4. MySQL服务器测试剩下的WHERE条件,基于测试结果选择接受或放弃改行数据。

如果查询优化器使用了ICP优化,那么在EXPLAINExtra会显示Using index condition

例如:
people包含了个人信息以及他们的地址,并且在表上定义了索引INDEX(zipcode, lastname, firstname),如果我们知道一个人的zipcode,但是不知道他们的lastname,那么我们可以使用如下语句进行查询:

SELECT * FROM people
WHERE zipcode='95054'
AND lastname LIKE '%etrunia%'
AND address LIKE '%Main Street%';

MySQL可以使用索引去定位那些zipcode='95054'的信息,但是第二个条件lastname LIKE '%etrunia%'却没法用于减少必须要扫描的表行,所以如果没有ICP优化,在执行此查询时必须读取所有zipcode='95054'的表行数据。

如果启用了ICP优化,因为MySQL使用了索引INDEX(zipcode, lastname, firstname),并且WHERE语句中的第二部分lastname LIKE '%etrunia%'仅仅使用了索引中的列lastname,所以在读取完整表行数据前可以基于此过滤那些索引中lastname不符合条件的索引数据,这样就能避免对那些满足zipcode='95054'但是不满足条件lastname LIKE '%etrunia%'表行数据的访问。

ICP可以通过系统变量optimizer_switch中的index_condition_pushdown进行启用和关闭:

SET optimizer_switch = 'index_condition_pushdown=off';
SET optimizer_switch = 'index_condition_pushdown=on';
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,047评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,807评论 3 386
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,501评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,839评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,951评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,117评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,188评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,929评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,372评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,679评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,837评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,536评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,168评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,886评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,129评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,665评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,739评论 2 351

推荐阅读更多精彩内容

  • 一、MySQL优化 MySQL优化从哪些方面入手: (1)存储层(数据) 构建良好的数据结构。可以大大的提升我们S...
    宠辱不惊丶岁月静好阅读 2,422评论 1 8
  • 今天看到一位朋友写的mysql笔记总结,觉得写的很详细很用心,这里转载一下,供大家参考下,也希望大家能关注他原文地...
    信仰与初衷阅读 4,726评论 0 30
  • InnoDB体系架构 上图简单显示了InnoDB存储引擎的体系架构图中可见,InnoDB存储引擎有多个内存块,可以...
    Rick617阅读 4,024评论 0 6
  • 1.A simple master-to-slave replication is currently being...
    Kevin关大大阅读 5,957评论 0 3
  • 索引 数据库中的查询操作非常普遍,索引就是提升查找速度的一种手段 索引的类型 从数据结构角度分 1.B+索引:传统...
    一凡呀阅读 2,886评论 0 8