MySQL培訓課程:MySQL Server系統架構
最新學訊:近期OCP認證正在報名中,因考試人員較多請盡快報名獲取最近考試時間,報名費用請聯系在線老師,甲骨文官方認證,報名從速!
我要咨詢MySQL培訓課程:MySQL Server系統架構
邏輯模塊組成
總的來說,MySQL可以看成是二層架構,第一層我們通常叫做SQLLayer,在MySQL數據庫系統處理底層數據之前的所有工作都是在這一層完成的,包括權限判斷,sql解析,執行計劃優化,querycache的處理等等;第二層就是存儲引擎層,我們通常叫做StorageEngineLayer,也就是底層數據存取操作實現部分,由多種存儲引擎共同組成。所以,可以用如下一張最簡單的架構示意圖來表示MySQL的基本架構,如圖所示:

雖然從上圖看起來MySQL架構非常的簡單,就是簡單的兩部分而已,但實際上每一層中都含有各自的很多小模塊,尤其是第一層SQLLayer,結構相當復雜的。下面我們就分別針對SQLLayer和StorageEngineLayer做一個簡單的分析。
SQL Layer 中包含了多個子模塊,下面我將逐個做一下簡單的介紹:
1、初始化模塊
顧名思議,初始化模塊就是在MySQLServer啟動的時候,對整個系統做各種各樣的初始化操作,比如各種buffer,cache結構的初始化和內存空間的申請,各種系統變量的初始化設定,各種存儲引擎的初始化設置,等等。
2、核心API
核心API模塊主要是為了提供一些需要非常高效的底層操作功能的優化實現,包括各種底層數據結構的實現,特殊算法的實現,字符串處理,數字處理等,小文件I/O,格式化輸出,以及最重要的內存管理部分。核心API模塊的所有源代碼都集中在mysys和strings文件夾下面,有興趣的讀者可以研究研究。
3、網絡交互模塊
底層網絡交互模塊抽象出底層網絡交互所使用的接口api,實現底層網絡數據的接收與發送,以方便其他各個模塊調用,以及對這一部分的維護。所有源碼都在vio文件夾下面。
4、Client&Server交互協議模塊
任何C/S結構的軟件系統,都肯定會有自己獨有的信息交互協議,MySQL也不例外。MySQL的Client&Server交互協議模塊部分,實現了客戶端與MySQL交互過程中的所有協議。當然這些協議都是建立在現有的OS和網絡協議之上的,如TCP/IP以及UnixSocket。
5、用戶模塊
用戶模塊所實現的功能,主要包括用戶的登錄連接權限控制和用戶的授權管理。他就像MySQL的大門守衛一樣,決定是否給來訪者“開門”。
6、訪問控制模塊
造訪客人進門了就可以想干嘛就干嘛么?為了安全考慮,肯定不能如此隨意。這時候就需要訪問控制模塊實時監控客人的每一個動作,給不同的客人以不同的權限。訪問控制模塊實現的功能就是根據用戶模塊中各用戶的授權信息,以及數據庫自身特有的各種約束,來控制用戶對數據的訪問。用戶模塊和訪問控制模塊兩者結合起來,組成了MySQL整個數據庫系統的權限安全管理的功能。
7、連接管理、連接線程和線程管理
連接管理模塊負責監聽對MySQLServer的各種請求,接收連接請求,轉發所有連接請求到線程管理模塊。每一個連接上MySQLServer的客戶端請求都會被分配(或創建)一個連接線程為其單獨服務。而連接線程的主要工作就是負責MySQLServer與客戶端的通信,接受客戶端的命令請求,傳遞Server端的結果信息等。線程管理模塊則負責管理維護這些連接線程。包括線程的創建,線程的cache等。
8、Query解析和轉發模塊
在MySQL中我們習慣將所有Client端發送給Server端的命令都稱為query,在MySQLServer里面,連接線程接收到客戶端的一個Query后,會直接將該query傳遞給專門負責將各種Query進行分類然后轉發給各個對應的處理模塊,這個模塊就是query解析和轉發模塊。其主要工作就是將query語句進行語義和語法的分析,然后按照不同的操作類型進行分類,然后做出針對性的轉發。
9、Query Cache 模塊
QueryCache模塊在MySQL中是一個非常重要的模塊,他的主要功能是將客戶端提交給MySQL的Select類query請求的返回結果集cache到內存中,與該query的一個hash值做一個對應。該Query所取數據的基表發生任何數據的變化之后,MySQL會自動使該query的Cache失效。在讀寫比例非常高的應用系統中,QueryCache對性能的提高是非常顯著的。當然它對內存的消耗也是非常大的。
10、Query優化器模塊
Query優化器,顧名思義,就是優化客戶端請求的query,根據客戶端請求的query語句,和數據庫中的一些統計信息,在一系列算法的基礎上進行分析,得出一個最優的策略,告訴后面的程序如何取得這個query語句的結果。
11、表變更管理模塊
表變更管理模塊主要是負責完成一些DML和DDL的query,如:update,delte,insert,createtable,altertable等語句的處理。
12、表維護模塊
表的狀態檢查,錯誤修復,以及優化和分析等工作都是表維護模塊需要做的事情。
13、系統狀態管理模塊
系統狀態管理模塊負責在客戶端請求系統狀態的時候,將各種狀態數據返回給用戶,像DBA常用的各種showstatus命令,showvariables命令等,所得到的結果都是由這個模塊返回的。
14、表管理器
這個模塊從名字上看來很容易和上面的表變更和表維護模塊相混淆,但是其功能與變更及維護模塊卻完全不同。大家知道,每一個MySQL的表都有一個表的定義文件,也就是*.frm文件。表管理器的工作主要就是維護這些文件,以及一個cache,該cache中的主要內容是各個表的結構信息。此外它還維護table級別的鎖管理。
15、日志記錄模塊
日志記錄模塊主要負責整個系統級別的邏輯層的日志的記錄,包括errorlog,binarylog,slowquerylog等。
16、復制模塊
復制模塊又可分為Master模塊和Slave模塊兩部分,Master模塊主要負責在Replication環境中讀取Master端的binary日志,以及與Slave端的I/O線程交互等工作。Slave模塊比Master模塊所要做的事情稍多一些,在系統中主要體現在兩個線程上面。一個是負責從Master請求和接受binary日志,并寫入本地relaylog中的I/O線程。另外一個是負責從relaylog中讀取相關日志事件,然后解析成可以在Slave端正確執行并得到和Master端完全相同的結果的命令并再交給Slave執行的SQL線程。
17、存儲引擎接口模塊
存儲引擎接口模塊可以說是MySQL數據庫中最有特色的一點了。目前各種數據庫產品中,基本上只有MySQL可以實現其底層數據存儲引擎的插件式管理。這個模塊實際上只是一個抽象類,但正是因為它成功地將各種數據處理高度抽象化,才成就了今天MySQL可插拔存儲引擎的特色。
各模塊工作配合
在了解了MySQL的各個模塊之后,我們再看看MySQL各個模塊間是如何相互協同工作的。接下來,我們通過啟動MySQL,客戶端連接,請求query,得到返回結果,最后退出,這樣一整個過程來進行分析。
當我們執行啟動MySQL命令之后,MySQL的初始化模塊就從系統配置文件中讀取系統參數和命令行參數,并按照參數來初始化整個系統,如申請并分配buffer,初始化全局變量,以及各種結構等。同時各個存儲引擎也被啟動,并進行各自的初始化工作。當整個系統初始化結束后,由連接管理模塊接手。連接管理模塊會啟動處理客戶端連接請求的監聽程序,包括tcp/ip的網絡監聽,還有unix的socket。這時候,MySQLServer就基本啟動完成,準備好接受客戶端請求了。
當連接管理模塊監聽到客戶端的連接請求(借助網絡交互模塊的相關功能),雙方通過Client&Server交互協議模塊所定義的協議“寒暄”幾句之后,連接管理模塊就會將連接請求轉發給線程管理模塊,去請求一個連接線程。
線程管理模塊馬上又會將控制交給連接線程模塊,告訴連接線程模塊:現在我這邊有連接請求過來了,需要建立連接,你趕快處理一下。連接線程模塊在接到連接請求后,首先會檢查當前連接線程池中是否有被cache的空閑連接線程,如果有,就取出一個和客戶端請求連接上,如果沒有空閑的連接線程,則建立一個新的連接線程與客戶端請求連接。當然,連接線程模塊并不是在收到連接請求后馬上就會取出一個連接線程連和客戶端連接,而是首先通過調用用戶模塊進行授權檢查,只有客戶端請求通過了授權檢查后,他才會將客戶端請求和負責請求的連接線程連上。
在MySQL中,將客戶端請求分為了兩種類型:一種是query,需要調用Parser也就是Query解析和轉發模塊的解析才能夠執行的請求;一種是command,不需要調用Parser就可以直接執行的請求。如果我們的初始化配置中打開了FullQueryLogging的功能,那么Query解析與轉發模塊會調用日志記錄模塊將請求計入日志,不管是一個Query類型的請求還是一個command類型的請求,都會被記錄進入日志,所以出于性能考慮,一般很少打開FullQueryLogging的功能。
當客戶端請求和連接線程“互換暗號(互通協議)”接上頭之后,連接線程就開始處理客戶端請求發送過來的各種命令(或者query),接受相關請求。它將收到的query語句轉給Query解析和轉發模塊,Query解析器先對Query進行基本的語義和語法解析,然后根據命令類型的不同,有些會直接處理,有些會分發給其他模塊來處理。
如果是一個Query類型的請求,會將控制權交給Query解析器。Query解析器首先分析看是不是一個select類型的query,如果是,則調用查詢緩存模塊,讓它檢查該query在querycache中是否已經存在。如果有,則直接將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解析與分發模塊分發過來的請求后,首先會通過訪問控制模塊檢查連接用戶是否有訪問目標表以及目標字段的權限,如果有,就會調用表管理模塊請求相應的表,并獲取對應的鎖。表管理模塊首先會查看該表是否已經存在于tablecache中,如果已經打開則直接進行鎖相關的處理,如果沒有在cache中,則需要再打開表文件獲取鎖,然后將打開的表交給表變更管理模塊。
當表變更管理模塊“獲取”打開的表之后,就會根據該表的相關meta信息,判斷表的存儲引擎類型和其他相關信息。根據表的存儲引擎類型,提交請求給存儲引擎接口模塊,調用對應的存儲引擎實現模塊,進行相應處理。
不過,對于表變更管理模塊來說,可見的僅是存儲引擎接口模塊所提供的一系列“標準”接口,底層存儲引擎實現模塊的具體實現,對于表變更管理模塊來說是透明的。他只需要調用對應的接口,并指明表類型,接口模塊會根據表類型調用正確的存儲引擎來進行相應的處理。
當一條query或者一個command處理完成(成功或者失敗)之后,控制權都會交還給連接線程模塊。如果處理成功,則將處理結果(可能是一個Resultset,也可能是成功或者失敗的標識)通過連接線程反饋給客戶端。如果處理過程中發生錯誤,也會將相應的錯誤信息發送給客戶端,然后連接線程模塊會進行相應的清理工作,并繼續等待后面的請求,重復上面提到的過程,或者完成客戶端斷開連接的請求。
如果在上面的過程中,相關模塊使數據庫中的數據發生了變化,而且MySQL打開了bin-log功能,則對應的處理模塊還會調用日志處理模塊將相應的變更語句以更新事件的形式記錄到相關參數指定的二進制日志文件中。
在上面各個模塊的處理過程中,各自的核心運算處理功能部分都會高度依賴整個MySQL的核心API模塊,比如內存管理,文件I/O,數字和字符串處理等等。
了解到整個處理過程之后,我們可以將以上各個模塊畫成如圖2-2的關系圖:

轉自 《MySQL性能調優與架構》