【性能提升神器】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