MySQL 覆盖索引的优点

一个通常的建议是为WHERE条件创建索引，但这其实是片面的。索引应当为全部查询设计，而不仅仅是WHERE条件。索引确实能有效地查找数据行，但MySQL也能够使用索引获取列数据，这样根本不需要去读取一行数据。毕竟，索引的叶子节点包含了索引对应的值。当年能够读取索引就能够拿到想要的数据时为什么还去读数据行呢？当索引包含了所有查询的数据时，这个索引就称之为覆盖索引。

覆盖索引能够成为一个非常有力的工具并且能够显著改善性能。考虑一下不读数据只需要读取索引的情况：

• 索引值通常会比整个行存储空间小很多，因此MySQL只读取索引值时可以只读取很少的数据。这对于缓存负荷来说十分重要——响应时间大部分消耗在复制数据。对于磁盘I/O而言也是一样，因为索引数据相比行数据存储空间小很多，因此更节省I/O负载和内存占用（对于MyISAM引擎更显著，因为MyISAM可以将索引打包使得存储空间更小）。
• 索引是按索引值的顺序存储的，因此I/O访问跨度相比随机磁盘位置获取行数据而言消耗的I/O频次更少。对于某些存储引擎，例如MyISAM和Percona XtraDB，你甚至能够使用OPTIMIZE优化表获得完全有序的索引，这会使得简单范围的查询完全使用顺序访问。
• 有些存储引擎，例如MyISAM，MySQL内存中只缓存索引。由于操作系统为MyISAM缓存了数据，访问时通常需要一个系统调用。这可能导致巨大的性能影响，尤其是对于缓存负荷场景来说，系统调用对于数据访问来说是最昂贵的代价。
• 由于InnoDB的聚集索引，覆盖索引对于InnoDB来说十分有帮助。InnoDB的辅助索引在其叶子节点中保存了行的主键值。因此，辅助索引覆盖查询后可以避免进行主键查询。
  

在所有的场景中，最典型的就是相比查找数据行，只包含索引列的查询的代价相当低。需要注意的是，聚集索引并不是任意类型的索引。聚集索引必须存储索引数据列对应的值。哈希，空间和全文索引并没有存储这些值，因此MySQL只能使用二叉树去覆盖查询。而且，不同的存储引擎实现覆盖索引的方式不同，并且并不是全部的存储引擎都支持覆盖索引（例如Memory存储引擎当前就不支持）。

当你验证查询中索引使用了覆盖索引时，使用Explain语句时，会在Extra列中看到“Using index”。例如，在store_goods表有一个(shop_id, goods_category_id1)的多列索引。MySQL可以在查询返回数据只有这两列时使用索引：

EXPLAIN SELECT `goods_category_id1`,`shop_id` FROM `store_goods` WHERE 1