【性能提高神器】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”建了索引，就会快速根据这个索引查询到符合条件的结果；而后再去这些符合条件的结果里查找所需的column一、column2字段；请注意，整个过程出现了两次查询，一次是查询索引，另外一次查询结果的所需字段。

那能不能将上面说的执行计划再优化一下呢？大杀器Covering Indexes就是用来干这事的。给column三、column一、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