MySQL邏輯架構

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

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

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

MySQL大多數核心服務均在中間這一層，包括查詢解析、分析、優(yōu)化、緩存、內置函數(比如：時間、數學、加密等函數)。所有的跨存儲引擎的功能也在這一層實現(xiàn)：存儲過程、觸發(fā)器、視圖等。

最下層為存儲引擎，其負責MySQL中的數據存儲和提取。和Linux下的文件系統(tǒng)類似，每種存儲引擎都有其優(yōu)勢和劣勢。中間的服務層通過API與存儲引擎通信，這些API接口屏蔽了不同存儲引擎間的差異。

MySQL使用基于成本的優(yōu)化器，它嘗試預測一個查詢使用某種執(zhí)行計劃時的成本，并選擇其中成本最小的一個。在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 |
+-----------------+-------------+

示例中的結果表示優(yōu)化器認為大概需要做6391個數據頁的隨機查找才能完成上面的查詢。這個結果是根據一些列的統(tǒng)計信息計算得來的，這些統(tǒng)計信息包括：每張表或者索引的頁面?zhèn)€數、索引的基數、索引和數據行的長度、索引的分布情況等等。

有非常多的原因會導致MySQL選擇錯誤的執(zhí)行計劃，比如統(tǒng)計信息不準確、不會考慮不受其控制的操作成本（用戶自定義函數、存儲過程）、MySQL認為的最優(yōu)跟我們想的不一樣（我們希望執(zhí)行時間盡可能短，但MySQL值選擇它認為成本小的，但成本小并不意味著執(zhí)行時間短）等等。

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

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

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

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

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

總結

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