說明：本文轉自 簡朝陽(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 中包含了多個子模塊，下面我將逐個做一下簡單的介紹：
1、初始化模塊
顧名思議，初始化模塊就是在MySQL Server 啓動的時候，對整個系統做各種各樣的初始化操作，比如各種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 以及Unix Socket。
5、用戶模塊
用戶模塊所實現的功能，主要包括用戶的登錄連接權限控制和用戶的授權管理。他就像MySQL 的大門守衛一樣，決定是否給來訪者“開門”。
6、訪問控制模塊
造訪客人進門了就可以想幹嘛就幹嘛麼？爲了安全考慮，肯定不能如此隨意。這時候就需要訪問控制模塊實時監控客人的每一個動作，給不同的客人以不同的權限。訪問控制模塊實現的功能就是根據用戶模塊中各用戶的授權信息，以及數據庫自身特有的各種約束，來控制用戶對數據的訪問。用戶模塊和訪問控制模塊兩者結合起來，組成了MySQL 整個數據庫系統的權限安全管理的功能。
7、連接管理、連接線程和線程管理
連接管理模塊負責監聽對MySQL Server 的各種請求，接收連接請求，轉發所有連接請求到線程管理模塊。每一個連接上MySQL Server 的客戶端請求都會被分配（或創建）一個連接線程爲其單獨服務。而連接線程的主要工作就是負責MySQL Server 與客戶端的通信，接受客戶端的命令請求，傳遞Server 端的結果信息等。線程管理模塊則負責管理維護這些連接線程。包括線程的創建，線程的cache 等。
8、Query 解析和轉發模塊
在MySQL 中我們習慣將所有Client端發送給Server 端的命令都稱爲query，在MySQL Server 裏面，連接線程接收到客戶端的一個Query 後，會直接將該query 傳遞給專門負責將各種Query 進行分類然後轉發給各個對應的處理模塊，這個模塊就是query 解析和轉發模塊。其主要工作就是將query 語句進行語義和語法的分析，然後按照不同的操作類型進行分類，然後做出針對性的轉發。
9、QueryCache 模塊
Query Cache 模塊在MySQL 中是一個非常重要的模塊，他的主要功能是將客戶端提交給MySQL 的Select 類query 請求的返回結果集cache 到內存中，與該query 的一個hash 值做一個對應。該Query 所取數據的基表發生任何數據的變化之後，MySQL 會自動使該query 的Cache 失效。在讀寫比例非常高的應用系統中，Query Cache 對性能的提高是非常顯著的。當然它對內存的消耗也是非常大的。
10、Query 優化器模塊
Query 優化器，顧名思義，就是優化客戶端請求的query，根據客戶端請求的query 語句，和數據庫中的一些統計信息，在一系列算法的基礎上進行分析，得出一個最優的策略，告訴後面的程序如何取得這個query 語句的結果。
11、表變更管理模塊
表變更管理模塊主要是負責完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語句的處理。
12、表維護模塊
表的狀態檢查，錯誤修復，以及優化和分析等工作都是表維護模塊需要做的事情。
13、系統狀態管理模塊
系統狀態管理模塊負責在客戶端請求系統狀態的時候，將各種狀態數據返回給用戶，像DBA 常用的各種showstatus 命令，showvariables 命令等，所得到的結果都是由這個模塊返回的。
14、表管理器
這個模塊從名字上看來很容易和上面的表變更和表維護模塊相混淆，但是其功能與變更及維護模塊卻完全不同。大家知道，每一個MySQL 的表都有一個表的定義文件，也就是*.frm文件。表管理器的工作主要就是維護這些文件，以及一個cache，該cache 中的主要內容是各個表的結構信息。此外它還維護table 級別的鎖管理。
15、日誌記錄模塊
日誌記錄模塊主要負責整個系統級別的邏輯層的日誌的記錄，包括error log，binary log，slow query log 等。
16、複製模塊
複製模塊又可分爲Master 模塊和Slave 模塊兩部分， Master 模塊主要負責在Replication 環境中讀取Master 端的binary 日誌，以及與Slave 端的I/O 線程交互等工作。
Slave 模塊比Master 模塊所要做的事情稍多一些，在系統中主要體現在兩個線程上面。一個是負責從Master請求和接受binary 日誌，並寫入本地relay log 中的I/O 線程。另外一個是負責從relay log 中讀取相關日誌事件，然後解析成可以在Slave 端正確執行並得到和Master端完全相同的結果的命令並再交給Slave 執行的SQL 線程。
17、存儲引擎接口模塊
存儲引擎接口模塊可以說是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 的關係圖：
下面這個是官方文檔裏的一個圖：
