一次mysql優化經歷

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

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

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

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

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

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

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

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

優化前後效能提公升10倍左右。

mysql的查詢優化有很多基礎理論，可以從查詢語句，表結構【分表，字段冗餘】，字段型別，索引，儲存引擎，快取，系統核心引數，磁碟io等方面考慮，但是很重要的一點是寫出具體的sql語句，針對這特定的語句進行具體的優化，當然前提是保證結果是準確的。