【夯實Mysql基礎】記一次mysql語句的最佳化過程！

標籤：plain   targe   art   mysql基礎   查詢最佳化   strong   用戶端   建立索引   分享   

　　1. 【事件起因】

 

　　今天在做項目的時候，發現提供給用戶端的介面時間很慢，達到了2秒多，我第一時間，抓了介面，看了啟動並執行sql，發現就是 2個sql慢，分別佔了1秒多。

　　一個sql是 連結了5個表同時使用了 2個 order by和 1個limit的分頁 sql。

      一個sql是上一個sql的count(*),即連結了5個表，當然沒有limit了(取總數)。

 

　　2. 【著手最佳化】

 

　　　　1）【最佳化思路】

　　　　　　　　第一條是 做client調用 service層的資料緩衝

　　　　　　　　第二條就是 最佳化sql本身。

　　　　　　　　這裡著重講一下 最佳化sql本身

 

　　　　2）【使用expain】

　　　　　　　　使用 explain語句，查看該語句，

　　　　　　　　　　　　　　　　看著沒有啥毛病啊,使用到了索引，掃描的行數也多，一個 85行，一個338多行，其他的也都是 1行。　　　　　　3）【使用子查詢最佳化】　　　　　　　　使用子查詢進行最佳化，效果差不多，只能想別的辦法　　　　4）【去掉order by排序】　　　　　　　　和同事討論時，覺得原來的5張表該加的索引都加了，為什麼速度慢呢，我說裡面還做了排序處理。　　　　　　　　說者無心，聽者有意。他說 你去掉排序試試，果然，去掉排序後，時間降到了 0.002秒，快了很多。　　　　　　　　但是order by排序為什麼很慢呢，因為 order by的那個欄位也是 有索引的。 　　　　5）【建立聯合索引】　　　　　　　　後來查詢了下面這篇文章（mysql中提高Order by語句查詢效率的兩個思路分析）才知道， 如果查詢出來的資料量很大的時候，order  by欄位，必須和前面的where語句中的欄位建立 聯合索引才行，同事建立的索引順序還得是 先是 where語句中的欄位最後是 order by中的欄位。　　　　6）【最終方案】　　　　　　　　　明白了道理，但是鑒於還得麻煩 DBA建立索引為 特定項目建立特定的索引也不划算。這部分資料一遍不經常變動，可以做成緩衝的形式，就作罷了，但是 分析問題的思路和最佳化 sql order的過程還是有收穫的 　　 3. 【參考資料】

【夯實Mysql基礎】記一次mysql語句的最佳化過程！