MySQL 条件分类及ICP特性
参考资料：
正文：
一个SQL中，条件的分类：
1. index key
条件中索引的前导列上的条件就是index key；
用于确定SQL查询在索引中的连续范围(起始范围+结束范围)的查询条件，被称之为Index Key。
由于一个范围，至少包含一个起始与一个终止，
因此Index Key也被拆分为Index First Key和Index Last Key，
分别用于定位索引查找的起始，以及索引查询的终止条件。
2. index filter
在所走索引上的其他字段上的条件(除了前导列上的索引列条件)就是index filter
在使用 index key 确定了起始范围和介绍范围之后，在此范围之内，
还有一些记录不符合where 条件，如果这些条件可以使用索引进行过滤，
那么就是 index filter
3. table filter
where中不在索引上的字段的条件，需要回表过滤的条件就叫table filter
where 中的条件不能使用索引进行处理的，只能访问table，进行条件过滤了。
就是回表进行过滤的
------------------------------------------------------------------------------
那么什么叫做ICP呢？
就是index condition pushdown
其实就是将index filter的条件下压到存储引擎层，减少了回表访问的记录数，
降低storage层返回给sever层的结果集大小
ICP(index condition pushdown)使用前后的比较：
1.ICP在使用前：
storage层：
只将满足index key条件的索引记录对应的整行记录取出，返回给server层
server
层：
对返回的数据，使用后面的where条件过滤，直至返回最后一行
总体过程图示：
storage层图示：
2.ICP在使用后：
storage层：
首先将index key条件满足的索引记录区间确定，然后在索引上使用index filter进行过滤
将满足的index filter条件的索引记录才去回表取出整行记录返回server层
不满足index filter条件的索引记录丢弃，不回表、也不会返回server层
server
层：
对返回的数据，使用table filter条件做最后的过滤。
总体过程图示：
storage图示：
使用前后的成本差别
使用前 比 使用后，存储层多返回了需要被index filter过滤掉的整行记录
使用ICP后，直接就去掉了不满足index filter条件的记录，
省去了他们回表和传递到server层的成本
ICP的使用条件：
- 只能用于二级索引(secondary index)。
- explain显示的执行计划中type值
（join 类型）为range、 ref、 eq_ref或者ref_or_null。
且查询需要访问表的整行数据，即不能直接通过二级索引的元组数据获得查询结果(索引覆盖)。
- ICP可以用于MyISAM和InnnoDB存储引擎，不支持分区表（5.7将会解决这个问题）