Schema的优化和索引 - 高性能的索引策略 - 覆盖索引(Covering Indexes)

核心提示： 现在MySQL在第一阶段的查询使用了覆盖索引，当它找到了在子查询匹配的行的时候，Schema的优化和索引 - 高性能的索引策略 - 覆盖索引(Covering Indexes)(4)，它不会在这个执行语句使用索引，但是总比没有强，sakila.actor 表使用了InnoDB并且在last_na

现在MySQL在第一阶段的查询使用了覆盖索引，当它找到了在子查询匹配的行的时候。它不会在这个执行语句使用索引。但是总比没有强。

这个优化的有效性完全依靠于有多少行被找到。假使products表包含了1百万行。让我们来看看不同数据集下这两个查询的表现。

第一个，Sean Carrey有30000个产品并且title包含Apollo有2000行。

第二个，分别是30000和40

第三个，分别是50和10

测试结果如下

Dataset 　 　 Original query 　 　 　 　 　 　 　 　 Optimized query
Example1 　5 queries per sec 　 　 　 　 　 　5 queries per sec
Example2 　7 queries per sec 　 　 　 　 　 　35 queries per sec
Example3 　2400 queries per sec 　 　 　2000 queries per sec

让我们解释下结果

在例子一中，返回的大数据集。并没有看到优化效果。大部分时间花在读取和发送数据上了。

例子二中，在索引过滤后，第二个条件过滤了很少的数据，让我们看看语句的油画效果：是没优化的语句的5倍之多！效率高的原因是第二个语句仅仅需要查找40行而不是30000行。

第三个例子中，知道了子查询是低效的。在索引过滤数据非常小的情况下，子查询的消耗大于了直接从整张表查询所有数据的消耗。

在MySQL5.1以及之前的版本中，这个优化有的时候可以避免读取没有必要的行。MySQL6.0就会避免一些额外的语句。如果升级的话，就不必优化了。

在大多数的存储引擎中，一个索引所覆盖仅仅是访问列是索引的一部分的查询语句。然而，InnoDB可以使优化更进一步。回忆一下，InnoDB的次要索引在叶子节点中保存了主键的值。意味着InnoDB次要索引可由一个额外的列了。InnoDB就可以使用这一特性来覆盖查询语句了。

举个例子，sakila.actor 表使用了InnoDB并且在last_name有个索引。因此这个索引能覆盖语句来获取主键的值actor_id，即使这一列技术上并不是索引的一部分。

mysql> EXPLAIN SELECT actor_id, last_name
　　 　-> FROM sakila.actor WHERE last_name = 'HOPPER'G
*************************** 1. row ***************************
　　 　 　 　 　 id: 1
　　select_type: SIMPLE
　　 　 　 　table: actor
　　 　 　 　 type: ref
possible_keys: idx_actor_last_name
　　 　 　 　 　key: idx_actor_last_name
　　 　 　key_len: 137
　　 　 　 　 　ref: const
　　 　 　 　 rows: 2
　　 　 　 　Extra: Using where; Using index