Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL 覆盖索引

MySQL 覆盖索引的优点

作者:岛上码农

当索引包含了所有查询的数据时,这个索引就称之为覆盖索引。覆盖索引能够成为一个非常有力的工具并且能够显著改善性能,本文将具体讲述覆盖索引的优点

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

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

在所有的场景中,最典型的就是相比查找数据行,只包含索引列的查询的代价相当低。需要注意的是,聚集索引并不是任意类型的索引。聚集索引必须存储索引数据列对应的值。哈希,空间和全文索引并没有存储这些值,因此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

覆盖索引查询在某些情况会让这样的优化失效。MySQL查询优化器在执行查询时会判断索引是否覆盖到。假设索引覆盖了WHERE条件,但没有覆盖整个查询。如果评估结果决定不走覆盖索引,那么MySQL 5.5及以前的版本会直接获取数据行,即便是不需要这些数据,然后才会过滤掉。

让我们看一下为什么这种情况会发生,然后如何重写查询以便解决这个问题。首先查询是这样的:

EXPLAIN SELECT * FROM products WHERE actor='SEAN CARREY' AND title like '%APOLLO%'

这个时候的结果是不会走覆盖索引,而是普通的索引,这是因为:

有一种方式可以使用巧妙的组合索引和重写查询条件。我们可以将索引扩展到(artist, title, prod_id),然后像下面那样重写查询语句:

EXPLAIN SELECT * 
FROM products
	JOIN (
    SELECT prod_id
    FROM products
    WHERE actor='SEAN CARREY' AND TITLE LIKE '%APOLLO%'
 ) AS t1 ON (t1.prod_id=products.prod_id)

我们称之为“递延JOIN(deferred join)”,因为它延迟了列的访问。在第一阶段的查询中,当它在子查询中找到了匹配的行的过程中,MySQL使用了覆盖索引。虽然在整个查询中没有覆盖到,但总比没有的好。

这种优化的效果好坏取决于WHERE条件查找到了多少行数据。假设products表包含了上百万行的数据。可以对比一下这两种查询的性能对比,总的数据为100万行。

对比结果如下表。

数据集 原始查询 优化后查询
第一种情况 5qps 5qps
第二种情况 7qps 35qps
第三种情况 2400qps 2000qps

结果的解释如下:

在大多数存储引擎中,一个索引只能够覆盖访问列是索引的一部分。然而,InnoDB实际上会做进一步的优化。想想InnoDB的的辅助索引在叶子节点中存储了主键的值。这意味着InnoDB的辅助索引实际上有了额外的列帮助InnoDB使用覆盖索引。 例如,sakila.actor表使用了InnoDB,然后在last_name有一个索引,因此这个索引能够覆盖或者主键actor_id的查询——即便这个列并不是索引的一部分。

EXPLAIN SELECT actor_id, last_name
FROM sakila.actor WHERE last_name = 'HOPPER'

以上就是MySQL 覆盖索引的优点的详细内容,更多关于MySQL 覆盖索引的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文