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