覆盖索引（Covering Index）
覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。
当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查询索引后再返回表操作，减少I/O提高效率。
如，表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。
当我们通过SQL语句：
select key2 from covering_index_sample where key1 = 'keytest';
的时候，就可以通过覆盖索引查询，无需回表。
但是以下SQL，因为不符合最左前缀匹配，虽然是索引覆盖，但是也无法用到索引（会扫描索引树）：
select key1 from covering_index_sample where key2 = 'keytest';
但是如果SQL中查询的信息不包含在联合索引中，那么就不会走索引覆盖。如：
select key2,key3 from covering_index_sample where key1 = 'keytest';
索引下推
索引下推是 MySQL 5.6引入了一种优化技术，默认开启，使用SET optimizer_switch = 'index_condition_pushdown=off'；可以将其关闭。
官方文档中给的例子和解释如下：people表中（zipcode, lastname, firstname）构成一个索引
SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%'；
如果没有使用索引下推技术，则MySQL会通过zipcode='95054'从存储引擎中查询对应的数据，返回到MySQL服务端，然后MySQL服务端基于lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断数据是否符合条件。
如果使用了索引下推技术，则MYSQL首先会返回符合zipcode='95054'的索引，然后根据lastname LIKE '%etrunia%'来判断索引是否符合条件。
如果符合条件，则根据该索引来定位对应的数据，如果不符合，则直接reject掉。有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。
当一条SQL使用到索引下推时，explain的执行计划中的extra字段内容为：Using index condition
也就是说，5.6版本前，先匹配到zipcode索引95054，然后拿此索引对应的主键去回表，到主键索引上找到对应的记录，再判断lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断数据是否符合条件。
那么5.6版本引入了索引下推，先匹配到zipcode索引，同时还会在索引里过滤lastname和address字段，拿着过滤完剩下的索引对应的主键id再回表查整行数据。
索引下推不止like
上面的例子中，提到了like，包括MySQL官网中也只提到了like，但是其实不止有Like。因为我认为索引下推其实是解决索引失效带来的效率低的问题的一种手段。
所以当联合索引中，某个非前导列因为索引失效而要进行扫表并回表时，就可以进行索引下推优化了。
如，有a,b联合索引，类型都是varchar，以下SQL也可以用到索引下推：
select d from t2 where a = "ni" and b = 1;
因为b字段因为类型不匹配导致索引失效了，但是通过下推优化其实是可以减少回表的次数的。
