某日運維突然說無線終端的頻道頁接口訪問量很大，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語句，針對這特定的語句進行具體的優化，當然前提是保證結果是准確的。
