9 張圖總結一下 MySQL 架構

前言

=====

目前大部分的後端開發人員對MySQL的理解可能停留在一個黑盒子階段。

MySQL基本使用沒什麼問題,比如建庫、建表、建索引,執行各種增刪改查。

所有很多後端開發人員眼中的MySQL如下圖所示

導致在實際工作中碰到MySQL中死鎖異常、SQL性能太差、異常報錯等問題時,直接百度搜索。

然後跟着博客搗鼓就解決了,可能自己都沒搞明白裏面的原理。

爲了解決這種知其然而不知其所以然的問題,阿星的重學 MySQL 系列會帶着大家去探索 MySQL 底層原理的方方面面。

這樣大家碰到MySQL的一些異常或者問題時,能夠直戳本質,快速地定位解決。

連接管理

系統(客戶端)訪問MySQL服務器前,做的第一件事就是建立TCP連接。

經過三次握手建立連接成功後,MySQL服務器對TCP傳輸過來的賬號密碼做身份認證、權限獲取。

接着我們來思考一個問題

一個系統只會和MySQL服務器建立一個連接嗎?

只能有一個系統和MySQL服務器建立連接嗎?

當然不是,多個系統都可以和MySQL服務器建立連接,每個系統建立的連接肯定不止一個。

所以,爲了解決TCP無限創建與TCP頻繁創建銷燬帶來的資源耗盡、性能下降問題。

MySQL服務器裏有專門的TCP連接池限制接數,採用長連接模式複用TCP連接,來解決上述問題。

TCP連接收到請求後,必須要分配給一個線程去執行,所以還會有個線程池,去走後面的流程。

這些內容我們都歸納到MySQL連接管理組件中。

所以連接管理的職責是負責認證、管理連接、獲取權限信息。

解析與優化

經過了連接管理,現在MySQL服務器已經獲取到SQL字符串。

如果是查詢語句,MySQL服務器會使用select SQL字符串作爲key

去緩存中獲取,命中緩存,直接返回結果(返回前需要做權限驗證),未命中執行後面的階段,這個步驟叫查詢緩存

需要注意,select SQL字符串要完全匹配,有任何不同的地方都會導致緩存不被命中(空格、註釋、大小寫、某些系統函數)。

小貼士:雖然查詢緩存有時可以提升系統性能,但也不得不因維護這塊緩存而造成一些開銷,從 MySQL 5.7.20 開始,不推薦使用查詢緩存,並在 MySQL 8.0 中刪除。

沒有命中緩存,或者非select SQL就來到分析器階段了。

因爲系統發送過來的只是一段文本字符串,所以MySQL服務器要按照SQL語法對這段文本進行解析。

如果你的SQL字符串不符合語法規範,就會收到You have an error in your SQL syntax錯誤提醒

通過了分析器,說明SQL字符串符合語法規範,現在MySQL服務器要執行SQL語句了。

MySQL服務器要怎麼執行呢?

你需要產出執行計劃,交給MySQL服務器執行,所以來到了優化器階段。

優化器不僅僅只是生成執行計劃這麼簡單,這個過程它會幫你優化SQL語句。

外連接轉換爲內連接、表達式簡化、子查詢轉爲連接、連接順序、索引選擇等一堆東西,優化的結果就是執行計劃。

截止到現在,還沒有真正去讀寫真實的表,僅僅只是產出了一個執行計劃。

於是就進入了執行器階段,MySQL服務器終於要執行SQL語句了。

開始執行的時候,要先判斷一下對這個表有沒有相應的權限,如果沒有,就會返回權限錯誤。

如果有權限,根據執行計劃調用存儲引擎API對錶進行的讀寫。

存儲引擎API只是抽象接口,下面還有個存儲引擎層,具體實現還是要看錶選擇的存儲引擎。

講到這裏,上面提到的查詢緩存、分析器、優化器、執行器都可以歸納到MySQL解析與優化組件中。

所以解析與優化的職責如下:

其中連接管理解析與優化處於MySQL架構中的Server層。

小結

在學習任何知識前,先不要着急的陷入細節,而是先了解大致脈絡,有個全局觀,之後再去深入相關的細節。

MySql架構分爲Servce層與存儲引擎層。

連接管理、解析與優化這些並不涉及讀寫表數據的組件劃分到Servce層,讀寫表數據而是交給存儲引擎層來做。

通過這種架構設計,我們發現Servce層其實就是公用層,存儲引擎層就是多態層,按需選擇具體的存儲引擎。

再細想下,它和模板方法設計模式一摸一樣,它們的執行流程是固定的,Servce層等於公用模板函數,存儲引擎層等於抽象模板函數,按需子類實現。

阿星最後以一張MySQL簡化版的架構圖結束本文,我們下期再見~

我是小富~,如果對你有用在看關注支持下,咱們下期見~

非常感謝各位小哥哥小姐姐們能看到這裏,原創不易,文章有幫助可以關注、點個贊、分享與評論,都是支持(莫要白嫖)!

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/GAH8hcT-pIln9NN1en1PLA