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就定義為慢查詢.