MySQL邏輯架構

如果能在頭腦中構建一幅MySQL各元件之間如何協同工作的架構圖，有助於深入理解MySQL伺服器。下圖展示了MySQL的邏輯架構圖。

MySQL邏輯架構，來自：高效能MySQL

MySQL邏輯架構整體分為三層，最上層為客戶端層，並非MySQL所獨有，諸如：連線處理、授權認證、安全等功能均在這一層處理。

MySQL大多數核心服務均在中間這一層，包括查詢解析、分析、優化、快取、內建函式(比如：時間、數學、加密等函式)。所有的跨儲存引擎的功能也在這一層實現：儲存過程、觸發器、檢視等。

最下層為儲存引擎，其負責MySQL中的資料儲存和提取。和Linux下的檔案系統類似，每種儲存引擎都有其優勢和劣勢。中間的服務層通過API與儲存引擎通訊，這些API介面遮蔽了不同儲存引擎間的差異。

MySQL使用基於成本的優化器，它嘗試預測一個查詢使用某種執行計劃時的成本，並選擇其中成本最小的一個。在MySQL可以通過查詢當前會話的last_query_cost的值來得到其計算當前查詢的成本。

示例程式碼

mysql> select * from t_message limit 10;
...省略結果集

mysql> show status like 'last_query_cost';
+-----------------+-------------+
| Variable_name | Value |
+-----------------+-------------+
| Last_query_cost | 6391.799000 |
+-----------------+-------------+

示例中的結果表示優化器認為大概需要做6391個數據頁的隨機查詢才能完成上面的查詢。這個結果是根據一些列的統計資訊計算得來的，這些統計資訊包括：每張表或者索引的頁面個數、索引的基數、索引和資料行的長度、索引的分佈情況等等。

有非常多的原因會導致MySQL選擇錯誤的執行計劃，比如統計資訊不準確、不會考慮不受其控制的操作成本（使用者自定義函式、儲存過程）、MySQL認為的最優跟我們想的不一樣（我們希望執行時間儘可能短，但MySQL值選擇它認為成本小的，但成本小並不意味著執行時間短）等等。

這裡last_query_cost的值是io_cost和cpu_cost的開銷總和，它通常也是我們評價一個查詢的執行效率的一個常用指標。

(1)它是作為比較各個查詢之間的開銷的一個依據。

(2)它只能檢測比較簡單的查詢開銷，對於包含子查詢和union的查詢是測試不出來的。

(3)當我們執行查詢的時候，MySQL會自動生成一個執行計劃，也就是query plan，而且通常有很多種不同的實現方式，它會選擇最低的那一個，而這個cost值就是開銷最低的那一個。

(4)它對於比較我們的開銷是非常有用的，特別是我們有好幾種查詢方式可選的時候。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。