覆盖索引_索引覆盖在哪一层

1、覆盖索引是联合索引的一个延伸与优化
2、覆盖索引的定义就是查询的列都包含在索引中。
3优点
3.1、索引条目通常远小于数据行大小，这样一次IO可以加载更多数据，减少ＩＯ次数
3.2、对于IO密集型的范围查询，因为索引是顺序存储的，所以会比随机从磁盘读取每一行数据的IO要少的多
3.3、对于InnoDB存储引擎，如果能从二级索引中获取要查询到的列，就可以避免对主键的二次查询
4、索引顺序的探讨
4.1、mysql能在索引中做最左前缀匹配的like比较，该操作可以转化为简单的比较操作，但是如果是通过通配符开头的like查询(%like%),则存储引擎无法做比较匹配。
4.2、对于sql排序来讲，扫描索引本身是很快的，但是如果索引无法覆盖查询所需要的全部列，则就需要每扫描一条就需要回表查询一次对应的行。
4.3、设计索引的时候应该尽量满足，索引既能排序，也能用于查找行数据。只有当索引中的列顺序与order by字句中的顺序完全一致，并且所有列的排序方向（倒序或者正序）都一样，mysql才能使用索引来对结果做排序。对于关联查询，只有当order by中引用的字段全部为第一个表，才能使用索引做排序。
4.4、当前导列是常量的时候，order by在不满足索引最左前缀要求的情况下，也可以使用索引做排序，例如（a,b,c）三列为联合索引，……WHERE a=5 order by b,c
4.5、 Index Key
用于确定SQL查询在索引中的连续范围(起始范围+结束范围)的查询条件，被称之为Index Key。由于一个范围，至少包含一个起始与一个终止，因此Index Key也被拆分为Index First Key和Index Last Key，分别用于定位索引查找的起始，以及索引查询的终止条件。
4.5.1、Index First Key
用于确定索引查询的起始范围。提取规则：从索引的第一个键值开始，检查其在where条件中是否存在，若存在并且条件是=、>=，则将对应的条件加入Index First Key之中，继续读取索引的下一个键值，使用同样的提取规则；若存在并且条件是>，则将对应的条件加入Index First Key中，同时终止Index First Key的提取；若不存在，同样终止Index First Key的提取。
select * from t1 where b >= 2 and b < 8 and c > 1 and d != 4 and e != ‘a’;
联合索引为b、c、d
针对上面的SQL，应用这个提取规则，提取出来的Index First Key为(b >= 2, c > 1)。由于c的条件为 >，提取结束，不包括d。
4.5.2、Index Last Key
Index Last Key的功能与Index First Key正好相反，用于确定索引查询的终止范围。提取规则：从索引的第一个键值开始，检查其在where条件中是否存在，若存在并且条件是=、<=，则将对应条件加入到Index Last Key中，继续提取索引的下一个键值，使用同样的提取规则；若存在并且条件是 < ，则将条件加入到Index Last Key中，同时终止提取；若不存在，同样终止Index Last Key的提取。
针对上面的SQL，应用这个提取规则，提取出来的Index Last Key为(b < 8)，由于是 < 符号，因此提取b之后结束。
4.6、Index Filter
Index Filter的提取规则：同样从索引列的第一列开始，检查其在where条件中是否存在：若存在并且where条件仅为 =，则跳过第一列继续检查索引下一列，下一索引列采取与索引第一列同样的提取规则；若where条件为 >=、>、<、<= 其中的几种，则跳过索引第一列，将其余where条件中索引相关列全部加入到Index Filter之中；若索引第一列的where条件包含 =、>=、>、<、<= 之外的条件，则将此条件以及其余where条件中索引相关列全部加入到Index Filter之中；若第一列不包含查询条件，则将所有索引相关条件均加入到Index Filter之中。
针对上面的用例SQL，索引第一列只包含 >=、< 两个条件，因此第一列可跳过，将余下的c、d两列加入到Index Filter中。因此获得的Index Filter为 c > 1 and d != 4 。
4.7、Table Filter
Table Filter是最简单，最易懂，也是提取最为方便的。提取规则：所有不属于索引列的查询条件，均归为Table Filter之中。
同样，针对上面的用例SQL，Table Filter就为 e != ‘a’
mysql5.5以及之前版本，会将index Filter放在服务器层进行过滤操作，但是在mysql5.6中则采用了Index Condition Pushdown做法，将index Filter下沉到存储引擎层来做过滤，这样返回服务器层的数据减少，则减少了服务器层进行table Filter的压力。