mysql優化一直是老生常談的問題，尤其在面試環節中，但在做mysql的優化之前，得先了解mysql的執行流程是怎樣，這樣才更好的去優化。
面試過程中也通常會問如果高併發或者使用者反映系統太卡，我們該怎麼去優化？
簡易的流程圖如下:
大致流程描述:
mysql查詢快取會儲存查詢返回的完整結構。當查詢命中該快取時，mysql會立刻返回結果，跳過了解析、優化和執行階段。 但查詢快取是預設不開啟的，且要求sql和引數都是一樣，同時查詢快取系統會跟蹤查詢中涉及的每乙個表，如果這些表發生變化，則該錶相關的所有快取資料均會失效。所以命中率一般較低，生產環境中也很少用到，具體流程就不描述了。如果感興趣的可以查閱詳細資料。
如果查詢快取未命中，則到解析器。解析器主要是對sql語句進行解析，使用mysqly語法規則進行驗證和解析查詢，並生成對應的解析樹。 得到解析數之後，還需要做預處理，預處理則進一步檢查解釋樹是否合法，以及進行一些優化，比如檢查資料表和列是否存在，如果有計算，會將計算的結果算出來等等。
查詢優化器是整個流程中重要的一環。查詢優化器會將預處理之後的解析樹轉化成執行計畫。一條查詢可以有多種執行方法，最後均會返回相同結果。查詢優化器的作用就是找到這其中最好的執行計畫。 生成執行計畫的過程會消耗較多的時間，特別是存在許多可選的執行計畫時。如果在一條sql語句執行的過程中將該語句對應的最終執行計畫進行快取，當相似的語句再次被輸入伺服器時，就可以直接使用已快取的執行計畫，從而跳過sql語句生成執行計畫的整個過程，進而可以提高語句的執行速度。 通常所講的優化sql，其實就是想讓查詢優化器，按照我們的思路,幫我們選擇最優的執行方案。
查詢執行計畫，就是mysql查詢中的執行計畫，比如是執行where語句還是from語句，下面有一張執行順序的圖。
最先執行的總是from操作，最後執行的是limit操作。其中每乙個操作都會產生一張虛擬的表，這個虛擬的表作為乙個處理的輸入，只是這些虛擬的表對使用者來說是透明的，但是只有最後乙個虛擬的表才會被作為結果返回。如果沒有在語句中指定某乙個子句，那麼將會跳過相應的步驟。
執行計畫會傳給查詢執行引擎，執行引擎選擇儲存引擎來執行計畫，到磁碟中的檔案中去查詢。 影響這個查詢效能最根本的原因是什麼? 其實是硬碟的機械運動，也就是我們平時熟悉的io，所以一條查詢語句是快還是慢，就是根據這個時間的io來確定的。那怎麼執行io又是什麼來確定的?就是傳過來的這乙份執行計畫.
時間索引 mysql mysql 時間索引執行計畫
專案中查詢時間斷的資料發現查詢時間很長。懷疑沒有走時間的索引，於是explain一下 explain select from t order where created at 2015 01 01 00 00 00 and created at 解析 id 表示執行的順序，id的值相同時，執行順序是...
Yii YII執行流程
yii整體執行流程直觀，具體由以下步驟 1 程式入口檔案index.php載入yii框架引導程式 bootstrap 檔案yii.php，載入配置檔案以及其他自定義配置。2 yii.php中yii類繼承了yiibase，主要封裝框架的一些通用方法，比如自動載入 建立元件 核心類路徑對映 記錄日誌以及...
MapReduce執行流程
mapreduce的大體流程是這樣的，如圖所示 由可以看到mapreduce執行下來主要包含這樣幾個步驟 1.首先對輸入資料來源進行切片 2.master排程worker執行map任務 3.worker讀取輸入源片段 4.worker執行map任務，將任務輸出儲存在本地 5.master排程work...