MySQL架構

一．MySQL邏輯架構

        第一層，即最上一層，所包含的服務並非MySQL所獨有的技術。它們都是服務於C/S程序或者是這些程序所須要的 ：鏈接處理，身份驗證，安全性等等。

        第二層值得關注。這是MySQL的核心部分。一般叫作 SQL Layer。在 MySQL據庫系統處理底層數據以前的全部工做都是在這一層完成的，包括權限判斷， sql解析，行計劃優化， query cache 的處理以及全部內置的函數(如日期,時間,數學運算,加密)等等。各個存儲引擎提供的功能都集中在這一層，如存儲過程，觸發器，視 圖等。

        第三層包括了存儲引擎。一般叫作StorEngine Layer ，也就是底層數據存取操做實現部分，由多種存儲引擎共同組成。它們負責存儲和獲取全部存儲在MySQL中的數據。就像Linux衆多的文件系統 同樣。每一個存儲引擎都有本身的優勢和缺陷。服務器是經過存儲引擎API來與它們交互的。這個接口隱藏 了各個存儲引擎不一樣的地方。對於查詢層儘量的透明。這個API包含了不少底層的操做。如開始一個事 物，或者取出有特定主鍵的行。存儲引擎不能解析SQL，互相之間也不能通訊。僅僅是簡單的響應服務器 的請求。

 

二．邏輯模塊組成

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

 

 SQL Layer 中包含了多個子模塊：

 

一、初始化模塊

        初始化模塊就是在MySQLServer啓動的時候，對整個系統作各類各樣的初始化操做，好比各類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 Server的各類請求，接收鏈接請求，轉發全部鏈接請求到線程管理模塊。每個鏈接上MySQL Server的客戶端請求都會被分配（或建立）一個鏈接線程爲其單獨服務。而鏈接線程的主要工做就是負責MySQL Server與客戶端的通訊，接受客戶端的命令請求，傳遞Server端的結果信息等。線程管理模塊則負責管理維護這些鏈接線程。包括線程的建立，線程的cache等。

 

八、Query解析和轉發模塊

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

 

九、Query Cache 模塊

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

 

十、Query優化器模塊

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

 

十一、表變動管理模塊

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

 

十二、表維護模塊

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

 

1三、系統狀態管理模塊

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

 

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日誌，並寫入本地relaylog中的I/O線程。另一個是負責從relaylog中讀取相關日誌事件，而後解析成能夠在Slave端正確執行並獲得和Master端徹底相同的結果的命令並再交給Slave執行的SQL線程。

 

1七、存儲引擎接口模塊

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

 

3、各模塊工做配合

       在瞭解了MySQL的各個模塊以後，咱們再看看MySQL各個模塊間是如何相互協同工做的。接下來，咱們經過啓動MySQL，客戶端鏈接，請求query，獲得返回結果，最後退出，這樣一整個過程來進行分析。

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

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

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

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

       當客戶端請求和鏈接線程「互換暗號（互通協議）」接上頭以後，鏈接線程就開始處理客戶端請求發送過來的各類命令（或者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處理完成（成功或者失敗）以後，控制權都會交還給鏈接線程模塊。若是處理成功，則將處理結果（多是一個Resultset，也多是成功或者失敗的標識）經過鏈接線程反饋給客戶端。若是處理過程當中發生錯誤，也會將相應的錯誤信息發送給客戶端，而後鏈接線程模塊會進行相應的清理工做，並繼續等待後面的請求，重複上面提到的過程，或者完成客戶端斷開鏈接的請求。

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

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

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

  

內容來源：《MySQL性能調優與架構》、《高性能MySQL》