mysql5.6 索引条件推送_《高性能MySQL》中，在索引中使用where条件过滤不匹配的记录,在存储器层面完成的，怎么理解？...

在索引中使用where条件过滤不匹配的记录,在存储器层面完成的

个人理解：这个应该是跟ICP有关,ICP就是 index condition pushdown 在说ICP之前，要先明白2个概念

1 index key

where语句后面 满足使用索引条件的索引字段

2 index filter

where语句后面 不满足使用索引条件的索引字段,但是仍然在索引中

只是看概念不好理解，下面说官方给出的一个例子

Suppose that we have a table containing information about people and their addresses and that the table has an index defined as INDEX (zipcode, lastname, firstname). If we know a person's zipcode value but are not sure about the last name, we can search like this:

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

MySQL can use the index to scan through people with zipcode='95054'. The second part (lastname LIKE '%etrunia%') cannot be used to limit the number of rows that must be scanned, so without Index Condition Pushdown, this query must retrieve full table rows for all the people who have zipcode='95054'.

With Index Condition Pushdown, MySQL will check the lastname LIKE '%etrunia%' part before reading the full table row. This avoids reading full rows corresponding to all index tuples that do not match the lastname condition.

Index Condition Pushdown is enabled by default; it can be controlled with the index_condition_pushdown flag. See Section 8.9.2, “Controlling Switchable Optimizations”.

这里indeex key就是zipcode 因为加了%再加上最左字段的原则,所以复合索引中所能使用的 索引字段就只有zipcode,在5.6版本之前存储引擎层面会 先筛选出来满足zipcode=95054的值,然后在二级索引中找出满足zipcode=95054的主键，进行回表操作,然后把查询到的数据返回给server，然后server层再过滤掉where条件中的数据。

支持ICP以后：存储引擎在找到zipcode=95054的数据以后，并不会马上进行回表操作，而是继续根据etrunia进行筛选，找出满足lastname LIKE '%etrunia%的数据以后，在进行回表操作,这里有2点好处 。第一：因为筛选掉一部分是数据，所以进行回表操作的次数也就是IO次数变少,假如第一个条件zipcode=95054筛选出来10万数据，第二条lastname LIKE '%etrunia%条件筛选出来2万数据，那么只需要进行2万次IO(这里可能说错了IO次数)第二个好处：返回给server层的数据会变少

使用限制：只有2级索引才可以使用ICP

在这个例子中zipcode是index key。 lastname是 index filter实际上，当你exlpan一条sql的时候

index key 就是当前使用的索引 key_len以后的值