MySQL探祕(二):SQL語句執行過程詳解

 昔日庖丁解牛,未見全牛,所賴者是其對牛內部骨架結構的瞭解,對於MySQL亦是如此,只有更加全面地瞭解SQL語句執行的每一個過程,才能更好的進行SQL的設計和優化。  當但願MySQL可以以更高的性能運行查詢時,最好的辦法就是弄清楚MySQL是如何優化和執行查詢的。一旦理解了這一點,不少查詢優化工做實際上就是遵循一些原則可以按照預想的合理的方式運行。  以下圖所示,當向MySQL發送一個請求的時候,MySQL到底作了什麼:mysql

  1. 客戶端發送一條查詢給服務器。
  2. 服務器先檢查查詢緩存,若是命中了緩存,則馬上返回存儲在緩存中的結果。不然進入下一階段。
  3. 服務器端進行SQL解析、預處理,再由優化器生成對應的執行計劃。
  4. MySQL根據優化器生成的執行計劃,再調用存儲引擎的API來執行查詢。
  5. 將結果返回給客戶端。

SQL語句執行過程

查詢緩存

 MySQL查詢緩存保存查詢返回的完整結構。當查詢命中該緩存時,MySQL會馬上返回結果,跳過了解析、優化和執行階段。  查詢緩存系統會跟蹤查詢中涉及的每一個表,若是這些表發生了變化,那麼和這個表相關的全部緩存數據都將失效。  MySQL將緩存存放在一個引用表中,經過一個哈希值引用,這個哈希值包括瞭如下因素,即查詢自己、當前要查詢的數據庫、客戶端協議的版本等一些其餘可能影響返回結果的信息。  當判斷緩存是否命中時,MySQL不會進行解析查詢語句,而是直接使用SQL語句和客戶端發送過來的其餘原始信息。因此,任何字符上的不一樣,例如空格、註解等都會致使緩存的不命中。  當查詢語句中有一些不肯定的數據時,則不會被緩存。例如包含函數NOW()或者CURRENT_DATE()的查詢不會緩存。包含任何用戶自定義函數,存儲函數,用戶變量,臨時表,mysql數據庫中的系統表或者包含任何列級別權限的表,都不會被緩存。  有一點須要注意,MySQL並非會由於查詢中包含一個不肯定的函數而不檢查查詢緩存,由於檢查查詢緩存以前,MySQL不會解析查詢語句,因此也沒法知道語句中是否有不肯定的函數。  事實則是,若是查詢語句中包含任何的不肯定的函數,那麼其查詢結果不會被緩存,由於查詢緩存中也沒法找到對應的緩存結果。  有關查詢緩存的配置以下所示。sql

  • query_cache_type:是否打開查詢緩存。能夠設置爲OFF、ON和DEMAND。DEMAND表示只有在查詢語句中明確寫明SQL_CACHE的語句纔會放入查詢緩存。
  • query_cache_size:查詢緩存使用的總內存空間。
  • query_cache_min_res_unit:在查詢緩存中分配內存塊時的最小單元。較小的該值能夠減小碎片致使的內存空間浪費,可是會致使更頻繁的內存塊操做。
  • query_cache_limit:MySQL可以查詢的最大查詢結果。若是查詢結果大於這個值,則不會被緩存。由於查詢緩存在數據生成的時候就開始嘗試緩存數據,因此當結果所有返回後,MySQL才知道查詢結果是否超出限制。超出以後,纔會將結果從查詢緩存中刪除。

 對查詢緩存的優化是數據庫性能優化的重要一環。判斷流程大體以下圖所示。數據庫

查詢緩存判斷流程圖

 緩存命中率能夠經過以下公式計算:Qcache_hits/(Qcache_hits + Com_select)來計算。緩存

解析和預處理

 解析器經過關鍵字將SQL語句進行解析,並生成對應的解析樹。MySQL解析器將使用MySQL語法規則驗證和解析查詢。  預處理器則根據一些MySQL規則進行進一步檢查解析書是否合法,例如檢查數據表和數據列是否存在,還會解析名字和別名,看看它們是否有歧義。性能優化

查詢優化器

 查詢優化器會將解析樹轉化成執行計劃。一條查詢能夠有多種執行方法,最後都是返回相同結果。優化器的做用就是找到這其中最好的執行計劃。  生成執行計劃的過程會消耗較多的時間,特別是存在許多可選的執行計劃時。若是在一條SQL語句執行的過程當中將該語句對應的最終執行計劃進行緩存,當類似的語句再次被輸入服務器時,就能夠直接使用已緩存的執行計劃,從而跳過SQL語句生成執行計劃的整個過程,進而能夠提升語句的執行速度。服務器

執行計劃緩存

 MySQL使用基於成本的查詢優化器(Cost-Based Optimizer,CBO)。它會嘗試預測一個查詢使用某種執行計劃時的成本,並選擇其中成本最少的一個。  優化器會根據優化規則對關係表達式進行轉換,這裏的轉換是說一個關係表達式通過優化規則後會生成另一個關係表達式,同時原有表達式也會保留,通過一系列轉換後會生成多個執行計劃,而後CBO會根據統計信息和代價模型(Cost Model)計算每一個執行計劃的Cost,從中挑選Cost最小的執行計劃。由上可知,CBO中有兩個依賴:統計信息和代價模型。統計信息的準確與否、代價模型的合理與否都會影響CBO選擇最優計劃。  有關優化器的原理十分複雜,這裏就不進行詳細講解了,你們能夠自行學習。微信

查詢執行引擎

 在解析和優化階段,MySQL將生成查詢對應的執行計劃,MySQL的查詢執行引擎根據這個執行計劃來完成整個查詢。這裏執行計劃是一個數據結構,而不是和其餘的關係型數據庫那樣生成對應的字節碼。數據結構

返回結果給客戶端

 若是查詢能夠被緩存,那麼MySQL在這個階段頁會將結果存放到查詢緩存中。  MySQL將結果集返回給客戶端是一個增量、逐步返回的過程。在查詢生成第一條結果時,MySQL就能夠開始向客戶端逐步返回結果集了。函數

訂閱最新文章,歡迎關注個人微信公衆號性能

參考

相關文章
相關標籤/搜索