WEB开发网
开发学院数据库MySQL Schema的优化和索引 - 高性能的索引策略 - 覆盖索... 阅读

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

 2009-09-02 00:00:00 来源:WEB开发网   
核心提示: 现在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

上一页  1 2 3 4 

Tags:Schema 优化 索引

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接