MySQL索引優化步驟總結

在項目使用mysql過程當中，隨着系統的運行，發現一些慢查詢，在這裏總結一下mysql索引優化步驟

1.開發過程優化

開發過程當中對業務表中查詢sql分析sql執行計劃(尤爲是業務流水錶)，主要是查看sql執行計劃，對sql進行優化。

explain執行計劃關鍵屬性

select_type,possible_keys,key,rows

(1) select_type 訪問類型

system>const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

system:表只有一行記錄（等於系統表）

eq_ref：惟一性索引掃描，對於每一個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 惟一索引掃描。

const:表示經過索引一次就找到了，const用於比較primary key 或者 unique索引。由於只需匹配一行數據，全部很快。若是將主鍵置於where列表中，mysql就能將該查詢轉換爲一個const

性能最好的是const，最差的是ALL

(2) possible_keys

查詢涉及到的字段上存在索引，則該索引將被列出，但不必定被查詢實際使用.

(3) key

實際使用的索引，若是爲NULL，則沒有使用索引(這條很關鍵)。

(4) rows

根據表統計信息及索引選用狀況，大體估算出找到所需的記錄所須要讀取的行數，越小越好.

2.上線前提交DBA審覈（流程）

對於關鍵系統上線前須要把數據表結構和索引提交DBA審覈(防止出現沒有索引)。

3.持續優化

部分業務表上線時因爲數據量很小不會產生慢查詢問題，或者上線後隨着業務需求變化，可能會產生慢查詢問題。

須要持續優化，能夠本身查詢sql日誌，找出慢查詢，關注dba發的慢查詢sql(通常力度比較粗，通常只有執行時間，沒有執行頻次)，

對於執行頻次比較多sql慢查詢的標準（執行時間）通常會要求更高。

藉助自動化運維工具，統計sql執行時間和頻率來區分慢查詢,好比報表服務執行超過1s爲慢查詢，而一個執行比較頻繁的sql(2C業務)超過50ms就定義爲慢查詢.