【性能提升神器】Covering Indexes

可能有小伙伴会问,Covering Indexes到底是什么神器呢?它又是如何来提升性能的呢?接下来我会用最通俗易懂的语言来进行介绍,毕竟不是每个程序猿都要像DBA那样深刻理解数据库,知道如何用以及如何用好神器才是最关键的。

Covering Indexes就是一个索引覆盖所有要查询的字段(ps:这句话我挖个坑,文末我来解释)。

An index that contains all required information to resolve the query is known as a “Covering Index” – it completely covers the query.
Covering Index includes all the columns, the query refers to in the SELECT, JOIN, and WHERE clauses.

 接下来我们通过一个非常简单的sql来进行分析:

SELECT column1, column2 FROM tablename WHERE column3=xxx;

你能想象将sql的执行时间从1.8秒,降到1.2秒,继续压榨到0.5,0.2.....,酣畅淋漓,怎一个爽字了得。就跟排兵布阵一样,打胜仗固然重要,但得想出成本最低效果最好的阵法,定会收获满满的成就感。

这条sql要如何来进行优化呢?第一反应可能就是说给“column3”加索引(普通索引或唯一索引)啊,没错,这样确实能在很大程度上提升这条sql的性能。

我们来分析下上面sql的执行计划:因为给“column3”建了索引,就会快速根据这个索引查询到符合条件的结果;然后再去这些符合条件的结果里查找所需的column1、column2字段;请注意,整个过程出现了两次查询,一次是查询索引,另一次查询结果的所需字段。

那能不能将上面说的执行计划再优化一下呢?大杀器Covering Indexes就是用来干这事的。给column3、column1、column2建个复合索引,如下:

alter table table_name add index index_column3 (column3,column1,column2) ;

这样就可以直接通过索引就能查询出符合条件的数据,而不必像上面那样先去查索引,然后再去查数据的两个过程

光说不练那是假把式!小伙伴们可以用explain去试试上面的两种情况,如果执行复合索引后的情况,你会发现Extra里出现Using index

刚开始我说挖了个坑,现在我把坑填上。既然神器Covering Indexes这么好用,以后select语句的我都不管三七二十一的都亮出神器。难不成你select *也要亮神器?一个表那么多字段,全建成索引?那索引文件会不堪重负的,这就会适得其反,带来一系列恶果的。索引文件过大会造成insert、update非常慢,你select倒是爽快了,不能不顾其他兄弟吧,不仗义的事咱不能干,切记!

如果看完这个分析还不过瘾,下面我给几篇参考文章:

https://www.c-sharpcorner.com/UploadFile/b075e6/improving-sql-performance-using-covering-indexes/

https://www.red-gate.com/simple-talk/sql/learn-sql-server/using-covering-indexes-to-improve-query-performance/

https://stackoverflow.com/questions/609343/what-are-covering-indexes-and-covered-queries-in-sql-server

https://stackoverflow.com/questions/62137/what-is-a-covered-index

 

posted on 2018-08-04 12:30  猿人谷  阅读(462)  评论(0编辑  收藏  举报