在上一篇文章[MySQL（五）｜《千萬級大數據查詢優化》第二篇：查詢性能優化（1）]中講到一條SQL的查詢執行路徑如下圖5-1所示：   圖5-1 步驟如下： 1. 客戶端發送一條查詢給服務器。 2. 服務器先檢查查詢緩存，如果命中了緩存，則立刻返回存儲在緩存中的結果。否則進行下一階段。 3. 服務器端進行SQL解析、預處理，再由優化器生成對應的執行計劃。 4. MySQL根據優化器生成的執行計劃，調用存儲引擎的API來執行查詢。 將結果返回給客戶端。 這一章節詳細講解下這一過程。 ### 1、通信協議 MySQL客戶端和服務端之間的通信協議是“半雙工”的，也就是說在任何一個時刻，那么是由服務端向客戶端發送數據，要么是由客戶端向服務端發送數據，這兩個動作不能同時發生。并且，一旦一端開始發送消息，另一端要接收完整個消息才能響應它。這就像來回拋球的游戲：在任何時刻，只有一個人能控制球，并且只有控制球的人才能將球拋回去（發送消息）。 當服務端開始響應客戶端請求時，客戶端必須完整地接收整個返回結果，而不是簡單地只取前面幾條結果，然后讓服務器停止發送數據。所以在前一章節的時候我們強烈在分頁時一定要使用LIMIT限制MySQL只返回需要的數據的原因。 ### 2、查詢狀態 每一個MySQL查詢，任何時間都會有一個狀態，該狀態表示了MySQL當前正在做什么。我一般使用`SHOW FULL PROCESSLIST`命令查看當前SQL執行，包括執行狀態、是否鎖表等信息，如下圖5-2所示。  圖5-2 該命令返回結果中的Command列表示當前的狀態。在一個查詢額生命周期中，狀態會變化很多次。MySQL官方手冊中對這些狀態值的含義有最權威的解釋。 * Sleep 線程正在等待客戶端發送新的請求。 * Query 線程正在執行查詢或者正在將結果發送給客戶端。 * Locked 在MySQL服務器層，該線程正在等待表鎖。在存儲引擎級別實現的鎖，例如InnoDB的行鎖，并不會體現在線程狀態中。對于MyISAM來說這是一個比較典型的狀態，但是其他沒有行鎖的引擎中也經常會出現。 * Analyzing and statistics 線程正在收集存儲引擎的統計信息，并生成查詢的執行計劃。 * Copying to tmp table \[on disk\] 線程正在執行查詢，并且將結果集都復制到一個臨時表中，這種狀態一般要么是在做 GROUP BY 操作，要么是文件排序操作，或者是UNION操作。如果這個狀態后面還有“on disk”標記，那表示MySQL正在將一個內存臨時表放到磁盤上。 * Sorting result 線程正在對結果集進行排序。 * Sending data 這表示多種情況：線程可能在多個狀態之間傳送數據，或者在生成結果集，或者在客戶端發送請求。 了解這些狀態的基本含義非常有用，這可以讓我們很快了解當前“誰正在持球”。 ### 3、查詢緩存 當緩存中有需要查詢的數據時，會直接從緩存中拿到結果并返回給客戶端，不會生成執行計劃，SQL也不會被執行。關于緩存更多的內容以后再講。 ### 4、查詢優化處理 任何緩存中沒有需要的數據，下一步就是服務器端進行SQL解析、預處理，再由優化器生成對應的執行計劃。 SQL解析和預處理主要驗證是否使用了錯誤的關鍵字、語法是否有誤、數據表和數據列是否存在，名稱和別名是否有歧義等問題。 當語法驗證都是合法的之后，優化器會將SQL轉化為執行計劃。一條SQL查詢有很多種執行方式，最后都返回相同的結果。優化器的作用就是找到這其中最好的執行計劃。 ### 5、查詢執行引擎 調用存儲引擎的API來執行查詢，這里沒有太多可以優化的地方。 ### 6、返回結果給客戶端 查詢執行的最后一個階段是將結果返回給客戶端。 關于查詢性能優化話題更多的內容，建議讀者自己閱讀相關的內容，比如《高性能MySQL》書籍的第六章。因為我這邊沒有使用到，就不做過多的講解啦