mysql5.6新功能索引条件下推（转载）

原文地址：http://www.cnblogs.com/zengkefu/p/5684101.html

一什么是"索引条件下推"

"索引条件下推"，称为 Index Condition Pushdown (ICP)，这是MySQL提供的用某一个索引对一个特定的表从表中获取元组"，注意我们这里特意强调了"一个"，这是因为这样的索引优化不是用于多表连接而是用于单表扫描，确切地说，是单表利用索引进行扫描以获取数据的一种方式。

二 "索引条件下推"的目的

用ySQL官方手册描述：

The goal of ICP is to reduce the number of full-record reads and thereby reduce IO operations. For InnoDB clustered indexes, the complete record is already read into the InnoDB buffer. Using ICP in this case does not reduce IO.

这句官方描述，一是说明减少完整记录（一条完整元组）读取的个数；二是说明对于InnoDB聚集索引无效，只能是对SECOND INDEX这样的非聚集索引有效。

三原理

先看实例：

mysql> set optimizer_switch='index_condition_pushdown=off'; //关闭ICP
Query OK, 0 rows affected (0.00 sec)

mysql> EXPLAIN SELECT * FROM t4 WHERE 1=t4.a4 AND t4.name like 'char%';
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t4    | NULL       | range | a4_i          | a4_i | 28      | NULL |    1 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> set optimizer_switch='index_condition_pushdown=on';  //打开ICP，则Extra列中显示"Using index condition"
Query OK, 0 rows affected (0.00 sec)

mysql> EXPLAIN SELECT * FROM t4 WHERE 1=t4.a4 AND t4.name like 'char%';
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | t4    | NULL       | range | a4_i          | a4_i | 28      | NULL |    1 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

如果打开ICP，则执行计划的Extra列会显示"Using index condition"，这表明在。

借用网上的2张图加以改造，并配以解释，来说明原理，更清晰地说明问题。

图一：不使用ICP技术（过程使用数字符号标示，如①②③等）

过程解释：

①：MySQL Server发出读取数据的命令，这是在执行器中执行如下代码段，通过函数指针和handle接口调用存储引擎的索引读或全表表读。此处进行的是索引读。
				

    if (in_first_read)
    {
      in_first_read= false;
      error= (*qep_tab->read_first_record)(qep_tab); //设定合适的读取函数，如设定索引读函数/全表扫描函数
    }
    else
      error= info->read_record(info);

②、③：进入存储引擎，读取索引树，在索引树上查找，把满足条件的（经过查找，红色的满足）从表记录中读出（步骤④，通常有IO），从存储引擎返回⑤标识的结果。此处，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤③），还要进行进行步骤④，通常有IO。
				

⑥：从存储引擎返回查找到的多条元组给MySQL Server，MySQL Server在⑦得到较多的元组。
				

⑦--⑧：⑦到⑧依据WHERE子句条件进行过滤，得到满足条件的元组。注意在MySQL Server层得到较多元组，然后才过滤，最终得到的是少量的、符合条件的元组。
				

图二：使用ICP技术（过程使用数字符号标示，如①②③等）

过程解释：

①：MySQL Server发出读取数据的命令，过程同图一。

②、③：进入存储引擎，读取索引树，在索引树上查找，把满足已经下推的条件的（经过查找，红色的满足）从表记录中读出（步骤④，通常有IO），从存储引擎返回⑤标识的结果。此处，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤③），还要在③这个阶段依据下推的条件进行进行判断，不满足条件的，不去读取表中的数据，直接在索引树上进行下一个索引项的判断，直到有满足条件的，才进行步骤④，这样，较没有ICP的方式，IO量减少。

⑥：从存储引擎返回查找到的少量元组给MySQL Server，MySQL Server在⑦得到少量的元组。因此比较图一无ICP的方式，返回给MySQL Server层的即是少量的、符合条件的元组。

 另外，图中的部件层次关系，不再进行解释。

四 实现细节
				

1 ICP只能用于辅助索引，不能用于聚集索引。
2 ICP只用于单表，不是多表连接是的连接条件部分（如开篇强调）
如果表访问的类型为：
3 EQ_REF/REF_OR_NULL/REF/SYSTEM/CONST: 可以使用ICP
4 range：如果不是"index tree only（只读索引）"，则有机会使用ICP
5 ALL/FT/INDEX_MERGE/INDEX_SCAN:  不可以使用ICP

五上楼

1 条件下推，一直是SQL优化的基本规则。所以，条件下推技术是常规技术。数据库的优化器几乎不会不实现条件下推优化。

2 技术层面，MySQL存在MySQL Server层和储存层，使得条件下推显得"有些割裂"。

3 非技术层面，MySQL之所以引入ICP，猜一猜或拍拍脑袋，原因你懂得。

六从代码的角度看

对于图一的解释,给出了读数据的代码片段,无论是关闭还是打开ICP, 从下面给出的函数调用关系可以看出,2幅图对应的情况下,代码路径是一致的.

首条元组读取调用关系(蓝色标识和非首条元组不同之处):

JOIN::exec()->do_select()->sub_select()->join_init_read_record()->rr_quick()->
  QUICK_RANGE_SELECT::get_next()->ha_innobase::multi_range_read_next()->
  DsMrr_impl::dsmrr_next()->handler::multi_range_read_next()->
  handler::read_range_first()->handler::ha_index_read_map()->
  handler::index_read_map()->ha_innobase::index_read()

除首条元组读取调用关系(蓝色标识和首条元组不同之处)

JOIN::exec()->do_select()->sub_select()->join_init_read_record()->rr_quick()->
  QUICK_RANGE_SELECT::get_next()->ha_innobase::multi_range_read_next()->
  DsMrr_impl::dsmrr_next()->handler::multi_range_read_next()->
  handler::read_range_next()->handler::ha_index_next()->
  ha_innobase::index_next()->ha_innobase::general_fetch()

ps：我的理解：如有一个复合索引a,b。此时对a = 10 and b>20 这种情况 type肯定是ref,根据a=10交给存储引擎执行索引搜索，将a=10的结果交给mysql sercie层之后，它在根据where进行过滤，也就是b > 20的过滤。但是有了索引条件下推，它就会把a = 10 and b>20两个条件一起交给存储引擎层，虽然还是按照a=10来搜索数据，不过在存储引擎层的时候，可以判断不符合b > 20的数据，直接丢弃。