一次mysql優化經歷

某日運維突然說無線終端的頻道頁介面訪問量非常大，memcache快取扛只是來。導致mysql併發查詢量太大，導致server不停地宕機，僅僅能不停地重新啟動機器。遺憾的是運維並沒有告訴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的結果是：

顯然，一對一關係的表，無需加入distinctkeyword【算是畫蛇添足吧】，去掉之後，再explain：

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

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