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