一次mysql最佳化經曆

標籤：mysql   最佳化   並發   database   

某日營運突然說無線終端的頻道頁介面訪問量很大，memcache緩衝扛不過來，導致mysql並發查詢量太大，導致伺服器不停地宕機，只能不停地重啟機器。遺憾的是營運並沒有告訴mysql查詢量具體有多大【無量化，比如一秒多少個查詢…】。

針對這個問題，有同事建議改了mysql+memcache的架構，採用redis儲存更佳。但是問題的真正原因是什麼呢？mysql一秒鐘扛幾百個並發查詢應該是可以的吧？帶著疑問，我讓營運給出慢查詢log。

Oh,my god…慢查詢記錄太多，都是一秒鐘以上的，但是基本上是同一條語句的查詢。explain一下：

Sql語句中有order by zj_lastupdate，明明在這個欄位上建立了索引的，但為什麼沒用呢【這個表上建立了太多聯合索引，以致zj_lastupdate被無視了】，所以導致這條查詢使用了暫存資料表【using temporary】和檔案排序【usingfilesort】。

 解決的辦法是在sql語句中加上use index(zj_lastupdate)，提醒mysql引擎使用指定索引欄位。再explain一下：

顯然，這次查詢引擎會使用zj_lastupdate了。

最佳化的效果是相當的明顯，從之前的1.5秒降到0.015秒，百倍的效能提升。當然，這個問題解決之後，也就沒有出現宕機的情形了，我們也沒有改架構。

 

再說一個mysql最佳化經曆，2表相連，一對一的關係，最佳化之前的sql語句大概是selectdistinct(movieid) as id…，explain的結果是：

顯然，一對一關聯性的表，無需添加distinct關鍵字【算是畫蛇添足吧】，去掉之後，再explain：

最佳化前後效能提升10倍左右。

Mysql的查詢最佳化有很多基礎理論，可以從查詢語句，表結構【分表，欄位冗餘】，欄位類型，索引，儲存引擎，緩衝，系統核心參數，磁碟IO等方面考慮，但是很重要的一點是寫出具體的sql語句，針對這特定的語句進行具體的最佳化，當然前提是保證結果是準確的。