MySQL 系統架構 說明

說明：本文轉自 簡朝陽(MySQL ACE)的 《MySQL性能調優與架構設計》

 

一.邏輯模塊組成

總的來講，MySQL 能夠當作是二層架構，第一層咱們一般叫作SQL Layer，在MySQL 數據庫系統處理底層數據以前的全部工做都是在這一層完成的，包括權限判斷，sql 解析，執行計劃優化，querycache 的處理等等；第二層就是存儲引擎層，咱們一般叫作Storage Engine Layer，也就是底層數據存取操做實現部分，由多種存儲引擎共同組成。因此，能夠用以下一張最簡單的架構示意圖來表示MySQL 的基本架構，如圖2-1 所示：

雖然從上圖看起來MySQL 架構很是的簡單，就是簡單的兩部分而已，但實際上每一層中都含有各自的不少小模塊，尤爲是第一層SQL Layer，結構至關複雜的。下面咱們就分別針對SQL Layer 和Storage Engine Layer 作一個簡單的分析。

SQL Layer 中包含了多個子模塊，下面我將逐個作一下簡單的介紹：

一、初始化模塊

顧名思議，初始化模塊就是在MySQL Server 啓動的時候，對整個系統作各類各樣的初始化操做，好比各類buffer，cache 結構的初始化和內存空間的申請，各類系統變量的初始化設定，各類存儲引擎的初始化設置，等等。

二、核心API

核心API 模塊主要是爲了提供一些須要很是高效的底層操做功能的優化實現，包括各類底層數據結構的實現，特殊算法的實現，字符串處理，數字處理等，小文件I/O，格式化輸出，以及最重要的內存管理部分。核心API 模塊的全部源代碼都集中在mysys和strings文件夾下面，有興趣的讀者能夠研究研究。

三、網絡交互模塊

底層網絡交互模塊抽象出底層網絡交互所使用的接口api，實現底層網絡數據的接收與發送，以方便其餘各個模塊調用，以及對這一部分的維護。全部源碼都在vio 文件夾下面。

四、Client& Server 交互協議模塊

任何C/S 結構的軟件系統，都確定會有本身獨有的信息交互協議，MySQL 也不例外。MySQL的Client & Server 交互協議模塊部分，實現了客戶端與MySQL 交互過程當中的全部協議。固然這些協議都是創建在現有的OS 和網絡協議之上的，如TCP/IP 以及Unix Socket。

五、用戶模塊

用戶模塊所實現的功能，主要包括用戶的登陸鏈接權限控制和用戶的受權管理。他就像MySQL 的大門守衛同樣，決定是否給來訪者「開門」。

六、訪問控制模塊

造訪客人進門了就能夠想幹嗎就幹嗎麼？爲了安全考慮，確定不能如此隨意。這時候就須要訪問控制模塊實時監控客人的每個動做，給不一樣的客人以不一樣的權限。訪問控制模塊實現的功能就是根據用戶模塊中各用戶的受權信息，以及數據庫自身特有的各類約束，來控制用戶對數據的訪問。用戶模塊和訪問控制模塊二者結合起來，組成了MySQL 整個數據庫系統的權限安全管理的功能。

七、鏈接管理、鏈接線程和線程管理

鏈接管理模塊負責監聽對MySQL Server 的各類請求，接收鏈接請求，轉發全部鏈接請求到線程管理模塊。每個鏈接上MySQL Server 的客戶端請求都會被分配（或建立）一個鏈接線程爲其單獨服務。而鏈接線程的主要工做就是負責MySQL Server 與客戶端的通訊，接受客戶端的命令請求，傳遞Server 端的結果信息等。線程管理模塊則負責管理維護這些鏈接線程。包括線程的建立，線程的cache 等。

八、Query 解析和轉發模塊

在MySQL 中咱們習慣將全部Client端發送給Server 端的命令都稱爲query，在MySQL Server 裏面，鏈接線程接收到客戶端的一個Query 後，會直接將該query 傳遞給專門負責將各類Query 進行分類而後轉發給各個對應的處理模塊，這個模塊就是query 解析和轉發模塊。其主要工做就是將query 語句進行語義和語法的分析，而後按照不一樣的操做類型進行分類，而後作出針對性的轉發。

九、QueryCache 模塊

Query Cache 模塊在MySQL 中是一個很是重要的模塊，他的主要功能是將客戶端提交給MySQL 的Select 類query 請求的返回結果集cache 到內存中，與該query 的一個hash 值作一個對應。該Query 所取數據的基表發生任何數據的變化以後，MySQL 會自動使該query 的Cache 失效。在讀寫比例很是高的應用系統中，Query Cache 對性能的提升是很是顯著的。固然它對內存的消耗也是很是大的。

十、Query 優化器模塊

Query 優化器，顧名思義，就是優化客戶端請求的query，根據客戶端請求的query 語句，和數據庫中的一些統計信息，在一系列算法的基礎上進行分析，得出一個最優的策略，告訴後面的程序如何取得這個query 語句的結果。

十一、表變動管理模塊

表變動管理模塊主要是負責完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語句的處理。

十二、表維護模塊

表的狀態檢查，錯誤修復，以及優化和分析等工做都是表維護模塊須要作的事情。

1三、系統狀態管理模塊

系統狀態管理模塊負責在客戶端請求系統狀態的時候，將各類狀態數據返回給用戶，像DBA 經常使用的各類showstatus 命令，showvariables 命令等，所獲得的結果都是由這個模塊返回的。

1四、表管理器

這個模塊從名字上看來很容易和上面的表變動和表維護模塊相混淆，可是其功能與變動及維護模塊卻徹底不一樣。你們知道，每個MySQL 的表都有一個表的定義文件，也就是*.frm文件。表管理器的工做主要就是維護這些文件，以及一個cache，該cache 中的主要內容是各個表的結構信息。此外它還維護table 級別的鎖管理。

1五、日誌記錄模塊

日誌記錄模塊主要負責整個系統級別的邏輯層的日誌的記錄，包括error log，binary log，slow query log 等。

1六、複製模塊

複製模塊又可分爲Master 模塊和Slave 模塊兩部分， Master 模塊主要負責在Replication 環境中讀取Master 端的binary 日誌，以及與Slave 端的I/O 線程交互等工做。

Slave 模塊比Master 模塊所要作的事情稍多一些，在系統中主要體如今兩個線程上面。一個是負責從Master請求和接受binary 日誌，並寫入本地relay log 中的I/O 線程。另一個是負責從relay log 中讀取相關日誌事件，而後解析成能夠在Slave 端正確執行並獲得和Master端徹底相同的結果的命令並再交給Slave 執行的SQL 線程。

1七、存儲引擎接口模塊

存儲引擎接口模塊能夠說是MySQL 數據庫中最有特點的一點了。目前各類數據庫產品中，基本上只有MySQL 能夠實現其底層數據存儲引擎的插件式管理。這個模塊實際上只是一個抽象類，但正是由於它成功地將各類數據處理高度抽象化，才成就了今天MySQL 可插拔存儲引擎的特點。

二.各模塊工做配合

在瞭解了MySQL 的各個模塊以後，咱們再看看MySQL各個模塊間是如何相互協同工做的。

接下來，咱們經過啓動MySQL，客戶端鏈接，請求query，獲得返回結果，最後退出，這樣一整個過程來進行分析。

當咱們執行啓動MySQL 命令以後，MySQL 的初始化模塊就從系統配置文件中讀取系統參數和命令行參數，並按照參數來初始化整個系統，如申請並分配buffer，初始化全局變量，以及各類結構等。同時各個存儲引擎也被啓動，並進行各自的初始化工做。當整個系統初始化結束後，由鏈接管理模塊接手。鏈接管理模塊會啓動處理客戶端鏈接請求的監聽程序，包括tcp/ip 的網絡監聽，還有unix 的socket。這時候，MySQL Server 就基本啓動完成，準備好接受客戶端請求了。

當鏈接管理模塊監聽到客戶端的鏈接請求（藉助網絡交互模塊的相關功能），雙方經過Client & Server 交互協議模塊所定義的協議「寒暄」幾句以後，鏈接管理模塊就會將鏈接請求轉發給線程管理模塊，去請求一個鏈接線程。

線程管理模塊立刻又會將控制交給鏈接線程模塊，告訴鏈接線程模塊：如今我這邊有鏈接請求過來了，須要創建鏈接，你趕快處理一下。鏈接線程模塊在接到鏈接請求後，首先會檢查當前鏈接線程池中是否有被cache 的空閒鏈接線程，若是有，就取出一個和客戶端請求鏈接上，若是沒有空閒的鏈接線程，則創建一個新的鏈接線程與客戶端請求鏈接。固然，鏈接線程模塊並非在收到鏈接請求後立刻就會取出一個鏈接線程連和客戶端鏈接，而是首先經過調用用戶模塊進行受權檢查，只有客戶端請求經過了受權檢查後，他纔會將客戶端請求和負責請求的鏈接線程連上。

在MySQL 中，將客戶端請求分爲了兩種類型：一種是query，須要調用Parser 也就是Query 解析和轉發模塊的解析纔可以執行的請求；一種是command，不須要調用Parser 就能夠直接執行的請求。若是咱們的初始化配置中打開了Full QueryLogging 的功能，那麼Query 解析與轉發模塊會調用日誌記錄模塊將請求計入日誌，無論是一個Query 類型的請求仍是一個command 類型的請求，都會被記錄進入日誌，因此出於性能考慮，通常不多打開Full QueryLogging 的功能。

當客戶端請求和鏈接線程「互換暗號（互通協議）」接上頭以後，鏈接線程就開始處理客戶端請求發送過來的各類命令（或者query），接受相關請求。它將收到的query語句轉給Query 解析和轉發模塊，Query 解析器先對Query 進行基本的語義和語法解析，而後根據命令類型的不一樣，有些會直接處理，有些會分發給其餘模塊來處理。

若是是一個Query 類型的請求，會將控制權交給Query解析器。Query 解析器首先分析看是否是一個select 類型的query，若是是，則調用查詢緩存模塊，讓它檢查該query 在query cache 中是否已經存在。若是有，則直接將cache 中的數據返回給鏈接線程模塊，而後經過與客戶端的鏈接的線程將數據傳輸給客戶端。若是不是一個能夠被cache 的query類型，或者cache 中沒有該query 的數據，那麼query 將被繼續傳回query 解析器，讓query解析器進行相應處理，再經過query 分發器分發給相關處理模塊。

若是解析器解析結果是一條未被cache 的select 語句，則將控制權交給Optimizer，也就是Query 優化器模塊，若是是DML 或者是DDL 語句，則會交給表變動管理模塊，若是是一些更新統計信息、檢測、修復和整理類的query 則會交給表維護模塊去處理，複製相關的query 則轉交給複製模塊去進行相應的處理，請求狀態的query 則轉交給了狀態收集報告模塊。實際上表變動管理模塊根據所對應的處理請求的不一樣，是分別由insert 處理器、delete 處理器、update 處理器、create 處理器，以及alter 處理器這些小模塊來負責不一樣的DML和DDL 的。

在各個模塊收到Query 解析與分發模塊分發過來的請求後，首先會經過訪問控制模塊檢查鏈接用戶是否有訪問目標表以及目標字段的權限，若是有，就會調用表管理模塊請求相應的表，並獲取對應的鎖。表管理模塊首先會查看該表是否已經存在於table cache 中，若是已經打開則直接進行鎖相關的處理，若是沒有在cache 中，則須要再打開表文件獲取鎖，而後將打開的表交給表變動管理模塊。

當表變動管理模塊「獲取」打開的表以後，就會根據該表的相關meta 信息，判斷表的存儲引擎類型和其餘相關信息。根據表的存儲引擎類型，提交請求給存儲引擎接口模塊，調用對應的存儲引擎實現模塊，進行相應處理。

不過，對於表變動管理模塊來講，可見的僅是存儲引擎接口模塊所提供的一系列「標準」接口，底層存儲引擎實現模塊的具體實現，對於表變動管理模塊來講是透明的。他只須要調用對應的接口，並指明表類型，接口模塊會根據表類型調用正確的存儲引擎來進行相應的處理。

當一條query 或者一個command 處理完成（成功或者失敗）以後，控制權都會交還給鏈接線程模塊。若是處理成功，則將處理結果（多是一個Result set，也多是成功或者失敗的標識）經過鏈接線程反饋給客戶端。若是處理過程當中發生錯誤，也會將相應的錯誤信息發送給客戶端，而後鏈接線程模塊會進行相應的清理工做，並繼續等待後面的請求，重複上面提到的過程，或者完成客戶端斷開鏈接的請求。

若是在上面的過程當中，相關模塊使數據庫中的數據發生了變化，並且MySQL 打開了binlog 功能，則對應的處理模塊還會調用日誌處理模塊將相應的變動語句以更新事件的形式記錄到相關參數指定的二進制日誌文件中。

在上面各個模塊的處理過程當中，各自的核心運算處理功能部分都會高度依賴整個MySQL的核心API 模塊，好比內存管理，文件I/O，數字和字符串處理等等。

 

瞭解到整個處理過程以後，咱們能夠將以上各個模塊畫成如圖2-2 的關係圖：

 

下面這個是官方文檔裏的一個圖：

 

本文轉載自：http://blog.csdn.net/tianlesoftware/article/details/7029112