MySQL之Covering Index

在网上随便搜搜,就能找到大把的关于MySQL优化的文章,不过里面很多都不准确,说个常见的:

SELECT a FROM … WHERE b = …

一般来说,很多文章会告诫你类似这样的查询,不要在“a”字段上建立索引,而应该在“b”上建立索引。这样做确实不错,但是很多时候这并不是最佳结果。为什么这样说?让我们先来分析一下查询的处理过程:在执行查询时,系统会查询“b”索引进行定位,然后再利用此定位去表里查询需要的数据“a”。也就是说,在这个过程中存在两次查询,一次是查询索引,另一次是查询表。那有没有办法用一次查询搞定问题呢?有,就是Covering Index!具体到此例中就是建立一个复合索引“b, a”,当查询进行时,通过复合索引的“b”部分去定位,至于需要的数据“a”,立刻就可以在索引里得到,从而省略了表查询的过程。

如果你想利用Covering Index,那么就要注意SELECT方式,只SElECT必要的字段,千万别SELECT *,因为我们不太可能把所有的字段一起做索引,虽然可以那样做,但那样会让索引文件过大,结果反倒会弄巧成拙。

如何才能确认查询使用了Covering Index呢?很简单,使用explain即可!只要在Extra里出现Using index就说明使用的是Covering Index。

知道了以上这些知识,估计对Coverging Index的了解也差不多了。再举一个例子,让大家印象深点:

比如说在文章系统里分页显示的时候,一般的查询是这样的:

SELECT id, title, content FROM article ORDER BY created DESC LIMIT 10000, 10;

一般这样的查询会把索引建在created字段,不过当LIMIT偏移很大时,查询效率仍然很低,改变一下查询:

SELECT id, title, content FROM article
INNER JOIN (
    SELECT id FROM article ORDER BY created DESC LIMIT 10000, 10
) AS page USING(id)
ORDER BY created DESC

此时,建立复合索引”created, id”就可以在子查询里利用上Covering Index,快速定位id,查询效率嗷嗷的。

觉得文章有用?立即: 和朋友一起 共学习 共进步!

猜想失败,您看看下面的文章有用吗?

2 thoughts on “MySQL之Covering Index

  1. Pingback: 一個例子與 InnoDB 索引的幾個概念 - 程序員的後花園

  2. 从天才的神坛,一夜跌落到了连普通人都不如的地步,这种打击,让得少年从此失魂落魄,天才之名,也是逐渐的被不屑与嘲讽所替代。

    站的越高,摔得越狠,这次的跌落,或许就再也没有爬起的机会。

    “下一个,萧薰儿!”

    喧闹的人群中,测试员的声音,再次响了起来。

    随着这有些清雅的名字响起,人群忽然的安静了下来,所有的视线,豁然转移

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>