MYSQL的架構設計是什么

這篇文章主要介紹了MYSQL的架構設計是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇MYSQL的架構設計是什么文章都會有所收獲，下面我們一起來看看吧。

1 前言

MYSQL的邏輯架構可分為3層:應用層、服務層、存儲引擎層。其中存儲引擎是MYSQL最有特色的地方，MySQL區別于其他數據庫的最重要特點是其插件式的表存儲引擎，本文也將著重聊聊最常用的innoDB存儲引擎的架構設計原理，假設現有如下sql：

update users set name=’zhangsan’ where id = 10

作為一個java服務端工程師，見到這樣一個sql，本能的腦海中立刻就浮現出如下信息：

• 一個表名為users的表

• 有兩個字段 id、name，id是主鍵

• 把users表里的id=10的這個用戶名修改為“zhangsan”

那么MYSQL是如何處理這樣一個sql呢？帶著這個問題，我們來看一下MYSQL是如何通過一個個組件來處理這個sql，來了解MYSQL的整體架構

2 應用層

2.1 連接線程處理

當MYSQL面對上面的sql，首先應該做什么呢？是如何解析？如何選擇索引？如何提交事務？當然不是，首先應該解決的是怎么把sql語句傳給它。大家都知道，如果我們要訪問數據庫，那么，首先就需要和數據庫建立連接，那么這個連接由誰來建呢，答案就是MYSQL驅動，下面這段maven配置大家應該都很熟悉

java程序就是通過這個驅動包來與數據庫建立網絡連接。

下圖示意：

從圖中可以看到這樣一個場景：java程序很多個線程并發請求執行上述sql，我們都知道數據庫連接是非常占用資源的，尤其是在高并發的情況下，如果每次都去建立數據庫連接就會有性能問題，也會影響一個應用程序的延展性，針對這個問題，連接池出現了。

下圖示意：

從圖中可見網絡連接交由線程3監聽和讀取sql請求，至此MYSQL已經收到我們的請求，當然MYSQL在建立連接時還做了用戶鑒權,鑒權依據是: 用戶名，客戶端主機地址和用戶密碼;在獲取連接后，處理請求時還會做sql請求的安全校驗，根據用戶的權限判斷用戶是否可以執行這條sql。

3 服務層

3.1 SQL 接口

從上圖中我們知道線程3負責監聽并讀取sql，拿到這個sql之后，如何執行是一項極其復雜的任務，所以MYSQL提供了SQL接口這么一個組件，線程3會將sql轉交給SQL接口來執行如下圖：

SQL接口具體處理功能有：DDL、DML、存儲過程、視圖、觸發器等。

3.2 SQL解析器

接著問題來了，SQL接口如何執行本文sql呢？，數據庫怎么理解本文這個sql呢？相信懂sql語法的人立馬就能知道什么意思，但是MYSQL是個系統不是人，它無法直接理解sql的意思，這個時候關鍵的組件出場了，SQL解析器的作用主要就是是解析sql語句，最終生成語法樹，比如本文sql就可以拆解成如下幾個部分：

• 需要從users表里更新數據

• 需要更新id字段是10的那行數據

• 需要把這行數據的name字段的值改為 “zhangsan”

3.3 SQL優化器

當通過SQL 解析器理解了sql語句要干什么之后，該如何實現呢，以本文的更新語句為例，我們可以有以下兩種實現方式：

• 直接定位到users表中id字段等于10的一行數據，然后查出這行數據數據，然后設置name字段為“zhangsan”；

• 也可以通過更新name字段索引的方式在name索引上遍歷id等于10的索引值，然后設置name字段為“zhangsan”。

上面兩種途徑都能實現最終結果，顯然第一種路徑更好一些，所以,SQL優化器就是從眾多實現路徑中選則一條最優的路徑出來，也就是我們常說的執行計劃。

3.4 執行器

通過SQL優化器我們得到一套執行計劃，那么，這個計劃怎么執行呢？這個時候就不得不提MYSQL存儲引擎，我們都知道MySQL和其他關系型數據庫不一樣的地方在于它的彈性以及可以通過插件形式提供不同種類的存儲引擎，類似java接口的多實現，MYSQL肯定會有一套標準的存儲引擎接口，而執行器就是按照執行計劃一步一步的調用存儲引擎接口完成sql執行而已，如下圖：

上圖專門將binlog標出來是為了和下文innodb存儲引擎的undo log、redo log做區分，強調binlog是server層的日志，后續binlog 和redo log的兩階段方式完成事務的提交會再次提到。

3.5 查詢緩存

MYSQL服務層為追求高效也引入了QUERY BUFFER 這個組件，但是這個組件比較雞肋，緩存不僅需要sql全字匹配命中，而且對基礎表的任何修改都會導致這些表的所有緩存失效，既不符合現在用戶變量的開發模式，大部分時候也不高效。

MYSQL從5.7開始不推薦使用默認關閉，8.0中不再支持，詳細原因如下圖：

截圖來源MYSQL開發者專區文檔：

4 存儲引擎層

4.1 概述

上文執行器拿到執行計劃后，調用存儲引擎的接口來完成sql的執行，那么存儲引擎如何幫助我們去訪問、操作內存以及磁盤上的數據呢？我們都知道MYSQL的存儲引擎有很多，實現方式各一，下面讓我們繼續通過上文的sql來初步了解我們常用的Innodb存儲引擎的核心原理和架構設計

重溫一下本文sql：

update users set name='zhangsan' where id = 10 —-歷史name = ‘lisi'

4.2 緩沖池（buffer pool）

InnoDB存儲引擎中有一個非常重要的放在內存里的組件，就是緩沖池（Buffer Pool），這里面會緩存很多的數據，以便于以后在查詢的時候，萬一你要是內存緩沖池里有數據，就可以不用去查磁盤了，如下圖：

緩沖池（buffer pool）在Innodb中的地位類似于我們現在系統設計中redis的地位，在Innodb中引入這一組件的就是為了高效的存取，我們都知道MYSQL查詢數據很快，究其原因不止是索引查詢，深層次的原因就是所有的增刪改查都是在buffer pool這塊內存上操作的，相比于操作磁盤，效率不言自明。

4.2.1 數據頁、緩存頁和臟頁

還是拿我們的sql舉例，更新id=10的這條記錄，難道從磁盤里只拉取id=10數據進入內存中嗎？很明顯不是，畢竟加入內存的記錄不止這一張表，而且單表每行記錄也不一樣，內存管理會非常困難的，所以，MYSQL對數據抽象出來的一個叫數據頁的邏輯概念，每頁固定大小默認16KB，可以存多條數據，并且buffer pool里的存儲結構和數據頁一致，這樣內存管理就會簡單的多，數據頁注冊元數據后加載進內存后就是緩存頁。

從圖中可以看到在緩存頁在sql更新完還未刷回硬盤時數據和磁盤中的數據頁是不一致的，這個時候我們稱這種緩存頁為臟頁。至于后續臟頁如何落盤暫時不提。

4.2.2 元數據

從上圖我們看到buffer pool中除了緩存頁，還多了一個元數據內存結構，這個可以簡單的理解為登記，比如因為疫情外地人回家過年會被當地政府進行登記，記錄從哪來、到哪去等信息，便于管理，buffer pool也是這樣做的；但是元數據可不止記錄緩存頁的磁盤地址和內存地址這么簡單，buffer pool核心原理都是通過元數據來實現的

4.2.3 free鏈表

buffer pool在MYSQL初始化的時候，就根據配置在內存中申請了一塊連續的空間，申請過后就按數據頁的大小和元數據的大小進行合理的劃分出很多個連續的、空的緩存頁,當需要查詢數據的時候就會從磁盤讀入數據頁放入到緩存頁當中,但是由于臟頁的存在，數據還未刷盤不能使用，那么數據頁加載進哪個緩存頁就是個問題。為了解決哪些緩存頁是空閑的，MYSQL團隊為Buffer pool設計了一個free鏈表，它是一個雙向鏈表的數據結構，這個free鏈表里每個節點就是一個空閑的緩存頁的元數據塊地址，也就是說只要一個緩存頁是空閑的，那么他的元數據塊就會放入這個free鏈表中,這樣加載數據頁是只需要從free鏈表中找空閑的緩存頁即可。

從圖中即可看出鏈表的大致結構，那么現在我們要更新users表中id=10的記錄，首先要知道id=10這條記錄的數據頁有沒有在緩存頁當中，然后在決定是否是加載數據頁還是直接使用緩存頁，所以，buffer pool里還有左下角這種hash表，用表空間+數據頁號作為key，緩存頁地址為value，可以快速判斷數據頁是否被緩存。

4.2.4 flush鏈表

本文sql執行更新后，這樣就導致內存中的數據和磁盤上的數據不一致，這就表明這個緩存頁是臟頁，臟頁是需要刷新到磁盤文件的。但是不可能所有緩存頁都刷回磁盤，比如有的緩存頁可能只是查詢的時候用到了，沒有別更新過，所以數據庫就引入flush鏈表，flush鏈表和free鏈表的實現方式一樣，都是在元數據中增加兩個指針做成雙向鏈表，用來標記鏈表上的都是臟頁，需要刷回磁盤，后續IO線程異步刷盤就是將flush鏈表的數據刷盤，然后把緩存頁移除flush鏈表，加入free鏈表當中。

4.2.5 LRU鏈表

隨著不停的把磁盤上的數據頁加載到空閑的緩存頁里去，free鏈表中空閑的緩存頁越來越少，如果free鏈表空了，這時候就無法從磁盤加載數據頁了，這時候就需要淘汰掉一些緩存頁，首先想到的就是把修改過的緩存頁刷新回磁盤上，然后清空這個緩存頁

具體選擇哪個緩存頁進行清空呢，數據庫引入LRU鏈表,結構和free鏈表基本一致,最近訪問的緩存頁都會被移動到LRU鏈表的頭部,這樣尾部的就是少訪問的數據，但是這樣的LRU有個問題，就是MYSQL的預讀機制，會把不常訪問或者不訪問的數據連帶著加載到內存，這樣就把這一部分也放在了LRU頭結點上，很明顯不合理,同理，全表掃描也有這個問題。

從上面可以看出，如果此時需要淘汰緩存頁，就可能把熱點數據提前淘汰掉。對于這種不合理的LRU算法MYSQL基于冷熱數據分離的方法對LRU算法進行如下優化：LRU鏈表被拆分為兩個部分，一部分熱數據，一部分冷數據，數據頁第一次加載到緩存的時候是放在冷數據表頭，在1s后再次訪問這個緩存頁，就很有可能是熱數據，就會把它挪到熱數據表頭區域，這樣設計防止了剛加載就訪問造成的假熱現象。

冷熱區域緩存頁移動規則如下：

• 冷數據 -> 熱數據：冷數據區的緩存頁是在 1s 后再被訪問到就移動到熱數據區的鏈表頭部

• 熱數據 -> 冷數據：能留在熱數據區域的緩存頁，證明都是緩存命中率比較高的，會經常被訪問到。如果每個緩存頁被訪問都移動到鏈表頭部，那這個操作將會非常的頻繁。所以 InnoDB 存儲引擎做了一個優化，只有在熱數據區域的后 3/4 的緩存頁被訪問了，才會移動到鏈表頭部；如果是熱數據區域的前 1/4 的緩存頁被訪問到，它是不會被移動到鏈表頭部去的。這樣盡可能的減少鏈表中節點的移動了

4.2.6 小結

現在我們了解了更新數據會先把數據加載進buffer pool在進行，了解buffer pool是如何通過冷熱數據分離的機制優化LRU鏈表，為系統設計中緩存過期淘汰策略提供的新的解決思路。既然，數據更新是把數據載入buffer pool中修改，那么更新完緩存頁之后數據庫是如何保證事務提交、如何保證數據頁和緩存頁數據一致的呢

4.3 undo log

說到事務就不得不提事務是如何回滾的，innodb是引入了undo log的日志組件來實現事務回滾的，以本文sql為例, 在數據加載進緩存頁后，修改之前，會將執行的sql取反保存在undo log中，邏輯類似sql：

update users set name='lisi' where id = 10

當然如果是insert語句與之對應的就是delete語句，delete語句也就對應的insert 語句，這也就明白為什么delete的數據是可以回滾，而truncate數據之后無法回滾的根本原因，在于truncate無法生成undo log。

上圖是本問sql執行的大致步驟，至于加入buffer pool這塊上文已經詳細了解過了，就不在贅述。從圖中可以看出因為log直接刷盤比較損耗性能，所以引入log buffer進行緩存，然后在通過異步的方式把數據刷入磁盤既然數據更新之前的數據記錄下來并成功刷入磁盤，則事務的回滾就不難實現了。

當然undo log 除了提供回滾功能，還為多版本并發控制（MVCC）提供了實現基礎，實現了MYSQL的非阻塞讀寫，提高了系統的并發性。本文也不再深入

4.4 redo log

下面來了解一下innodb是如何保證buffer pool緩存的數據一致性問題，數據更新值內存后并不會立即刷新至磁盤數據頁，而是一致以臟頁的形式保存在buffer pool當中，這樣做有兩個原因會導致效率很差，一個是內存向磁盤寫數據本身效率就慢，另一個就是隨機IO會寫磁盤的時間上附加上很多磁頭尋址的時間，所以立即刷數據頁效率很低。

Innodb是如何規避上述問題的呢，正常情況下，異步刷盤就已經可以解決了刷磁盤慢的問題，但是，假如MYSQL系統崩潰、宕機，這時候臟頁還未及時刷盤，那么緩存頁期間所有改動數據豈不是丟了，所以，Innodb引入了另一個組件redo log，專門記錄數據被緩存期間做過的修改記錄，然后立即寫入redo log磁盤文件，相比于緩存頁刷盤，redo log刷盤的數據了小多了，并且寫redo log是順序IO，而緩存頁刷盤是隨機IO。

下圖示意：

這樣當數據庫異常宕機時，即使緩存頁丟失數據也不會丟失，因為redo log已經落盤，數據庫重啟的時候會更近redo log把磁盤上歷史的數據頁重新載入內存，重新按redo log的修改記錄操作一遍就能將緩存頁中的數據恢復至宕機前的狀態。

如果系統宕機時，redo log還沒落盤數據豈不是丟了，對，這種情況下數據會丟，這種redo log丟數據分兩中情況：

第一種情況，MYSQL有三種刷盤策略，通過innodb_flush_log_at_trx_commit參數進行配置

• 配置為0：事務提交的時候不會把redolog buffer里的數據立即刷入磁盤，此時如果宕機則會導致已提交的數據修改丟失；

• 配置為1：則是事務提交的時候必須把redolog buffer里的數據刷入磁盤，以保證事務提交后操作數據日志不丟；

• 配置為2：則表示只是把數據交給操作系統進行刷盤，操作系統刷沒刷成功則不管，理論上操作系統刷盤是先要經過os cache內存緩存的，就是說數據會先在os chache里沒有真正的落盤，這種模式下也可能導致數據丟失

這第一種情況如果產生丟數據，是真的丟失，所以，如果對數據庫丟失數據零容忍，建議配置策略為1

第二種情況，就是未寫commit標記日志的情況，即下圖第9步丟失的情況，但是這種情況系統認為事務提交失敗，所以丟失了并不影響數據一致性。

圖中7、8、9三個步驟是事務提交commit的時候才做的（本文只用一個sql來講解，默認事務自動提交），redo log記錄更新記錄之后，執行器會把修改記錄寫在server層的binlog當中，很明顯這是兩個文件，如果出現上述宕機等異常情況，這兩個文件的數據一致性是不能保證的，所以，為了保證兩個文件的數據一致性，innodb會在binlog寫完之后在redo log中補上一個commit標記告訴redo log事務成功。事務執行成功后操作redo log刷入磁盤，sql執行成功。

關于“MYSQL的架構設計是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“MYSQL的架構設計是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。