什么是覆盖索引
覆盖索引一说为索引覆盖。
理解方式一：就是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。
理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了（或覆盖了）满足查询结果的数据就叫做覆盖索引。[1]
理解方式三：是非聚集复合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建索引的字段正好是覆盖查询条件中所涉及的字段，也即，索引包含了查询正在查找的数据）。[2]
2覆盖索引的使用以及作用
如果你想要通过索引覆盖select多列，那么需要给需要的列建立一个多列索引，当然如果带查询条件，where条件要求满足最左前缀原则。
Innodb的辅助索引叶子节点包含的是主键列，所以主键一定是被索引覆盖的。
（1）例如，在sakila的inventory表中，有一个组合索引(store_id,film_id)，对于只需要访问这两列的查 询，MySQL就可以使用索引，如下：
mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventoryG
（2）再比如说在文章系统里分页显示的时候，一般的查询是这样的：
SELECT id, title, content FROM article ORDER BY created DESC LIMIT 10000, 10;
通常这样的查询会把索引建在created字段（其中id是主键），不过当LIMIT偏移很大时，查询效率仍然很低，改变一下查询：
SELECT id, title, content FROM article
INNER JOIN (
SELECT id FROM article ORDER BY created DESC LIMIT 10000, 10
) AS page USING(id)
此时，建立复合索引"created, id"（只要建立created索引就可以吧，Innodb是会在辅助索引里面存储主键值的），就可以在子查询里利用上Covering Index，快速定位id，查询效率嗷嗷的。[3]
简单地说，就是在没必要查询所有字段的情况下，只查询某一个索引字段时就尽量少用*，因为索引是建立在内存中的，只取索引字段就可以从内存中获取，而不是去查询数据库，增加磁盘io。
下面是一个例子
话说有这么一个表：
CREATE TABLE `user_group` (
`id` int(11) NOT NULL auto_increment,
`uid` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `uid` (`uid`),
KEY `group_id` (`group_id`),
) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8
看AUTO_INCREMENT就知道数据并不多，75万条。然后是一条简单的查询：
SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;
很简单对不对?怪异的地方在于：
如果换成MyISAM做存储引擎的时候，查询耗时只需要0.01s，用InnoDB却会是0.15s左右
如果只是就这么点差距其实不是什么大不了的事，但是真实的业务需求比这个复杂，造成的差距也很大：MyISAM只需要0.12s，InnoDB则需要2.2s.，最终定位到问题症结是在这条SQL。
Explain的结果是：
+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+
| 1 | SIMPLE | user_group | ref | group_id | group_id | 4 | const | 5544 | |
+----+-------------+------------+------+---------------+----------+---------+-------+------+-------+
看起来已经用上索引了，而这条SQL语句已经简单到让我无法再优化了。最后请前同事Gaston诊断了一下，他认为：数据分布上，group_id相同的比较多，uid散列的比较均匀，加索引的效果一般，但是还是建议我试着加了一个多列索引：
ALTER TABLE user_group ADD INDEX group_id_uid (group_id, uid);
然后，不可思议的事情发生了……这句SQL查询的性能发生了巨大的提升，居然已经可以跑到0.00s左右了。经过优化的SQL再结合真实的业务需求，也从之前2.2s下降到0.05s。
再Explain一次：
+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+
| 1 | SIMPLE | user_group | ref | group_id,group_id_uid | group_id_uid | 4 | const | 5378 | Using index |
+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+
原来是这种叫覆盖索引(covering index)，MySQL只需要通过索引就可以返回查询所需要的数据，而不必在查到索引之后再去查询数据，所以那是相当的快!!但是同时也要求所查询的字段必须被索引所覆盖到，在Explain的时候，输出的Extra信息中如果有“Using Index”，就表示这条查询使用了覆盖索引。
不过，还有一个无法解释的问题就是，不用覆盖索引的情况下，为什么用MyISAM就快那么多，而InnoDB就慢这么多呢?求真相……