總的來說，MySQL可以看成是二層架構。
第一層我們通常叫做SQL Layer，在MySQL數據庫系統處理底層數據之前的所有工作都是在這一層完成的，包括權限判斷，sql解析，執行計划優化，query cache的處理等等；
第二層就是存儲引擎層，通常叫做Storage Engine Layer，也就是底層數據存儲操作實現部分，由多種存儲引擎共同組成。所以，可以用如下圖來MySQL的基礎架構。
SQL Layer中包含了多個子模塊
1、 初始化模塊
初始化模塊就是在MySQL Server啟動的時候，對整個系統做各種各樣的初始化操作，比如各種buffer,cache結構的初始化和內存空間的申請，各種系統變量的初始化設定，各種存儲引擎的初始化設置，等等。
2、 核心API
核心API模塊主要是為了提供一些非常高效的底層操作功能的優化實現，包括各種底層數據結構的實現，特殊算法的實現，字符串處理，數字處理等，小文件I/O，格式化輸出，以及最重要的內存管理部分。
3、 網絡交互模塊
底層網絡交互模塊抽象出底層網絡交互所使用的接口API，實現底層數據的接收與發送，以方便其他各個模塊調用，以及對一部分的維護。
4、 Client & Server 交互協議模塊
任何C/S結構的軟件系統，都肯定會有自己獨有的信息交換協議，MySQL也不例外。MySQL的Client & Server交互協議模塊部分，實現了客戶端與MySQL交互過程中的所有協議。當然這些協議都是建立在現有的OS和網絡協議基礎上的。
5、 用戶模塊
用戶模塊所實現的功能，主要包括用戶的登陸連接權限控制和用戶的授權管理。他就像MySQL的大門守衛一樣，決定是否給來訪者“開門”。
6、 訪問控制模塊
造訪客人進門了就可以想干嘛就干嘛么？為了安全考慮，這時候就需要訪問控制模塊實時監控客人的每一個動作，給不同的客人以不同的權限。訪問控制模塊實現的功能就是根據用戶模塊中各用戶的授權信息，以及數據庫自身特有的各種約束，來控制用戶對數據的訪問。用戶模塊和訪問控制模塊兩者結合起來，組成了MySQL整個數據庫系統的權限安全管理功能。
7、 連接管理、連接線程和線程管理
連接管理模塊負責監聽對MySQL Server的各種請求，接收連接請求，轉發所有連接請求到線程管理模塊，每一個連接上的MySQL Server的客戶端請求都會被分配（或創建）一個連接線程為其單獨服務。而連接線程的主要工作就是負責MySQL Server與客戶端的通信，接收客戶端的命令請求，傳遞Server端的結果信息等。線程管理模塊則負責管理維護這些連接線程，包括線程的創建，線程的cache等。
簡單的來說:連接模塊負責監控和轉發連接請求給線程管理模塊，線程管理模塊負責維護連接線程，連接線程負責與MySQL Server與客戶端通信。
8、Query解析和轉發模塊
在MySQL中我們習慣將所有的Client端發送給Server端命令都成為query，在MySQL Server里面，連接線程接收到客戶端的一個query后，會直接將該query傳遞給專門負責將各種query進行分類然后轉發給各個對應的處理模塊，這個模塊就是query解析和轉發模塊。其主要工作就是將query語句進行語義和語法解析，然后按照不同的操作類型進行分類，然后做出針對性的轉發。
9、 Query Cache模塊
Query Cache模塊在MySQL中是一個非常重要的模塊，他的主要功能是將客戶端提交給MySQL的Select類query請求的返回結果集cache到內存中，與該query的一個hash值做一個對應。該Query所取數據的基表發生任何的數據變化后，MySQL會自動使該query的Cache失效。在讀寫比較高的應用系統中，Query Cache對性能的提高是非常顯著的。當然它對內存的消耗也是非常大的。
10、 Query優化器模塊
Query優化器，就是優化客戶端請求的query,根據客戶端請求的query語句，和數據庫中的一些統計信息，在一系列算法的基礎上進行分析，得出一個最優的策略，告訴后面的程序如何取得這個query語句的結果。
11、 表變更管理模塊
表變更管理模塊主要是負責完成一些DML和DLL的query，如：update,delete,insert,create table,alter table等語句的處理。
12、 表維護模塊
表的狀態檢查，錯誤修復，以及優化和分析等工作都是表維護模塊需要做的事情。
13、 系統狀態管理模塊
系統狀態管理模塊負責在客戶端請求系統狀態的時候，將各種狀態數據返回給用戶，像DBA經常使用show status命令，show variables命令等，所得到的結果就是這個模塊返回的。
14、表管理器
這個模塊從名字上看來很容易和上面的表變更和表維護模塊相混淆，但是其功能與變更以及維護模塊卻完全不同，大家知道，每一個MySQL的表都有一個表的定義文件，也就是*.frm文件。表管理器的主要工作就是維護這些文件，以及一個cache，該cache中的主要內容時各個表的結構信息。此外還維護table級別的鎖管理。
15、 日志記錄模塊
日志記錄模塊主要負責整個系統級別的邏輯層的日志的記錄，包括err log，binary log，show query log等。
16、 復制模塊
復制模塊又可以分為Master模塊和Slave模塊兩部分，Master模塊主要負責在Relication環境中讀取Master端的binary日志，以及與Slave端的I/O線程交互等工作。Slave模塊比Master模塊索要做的事情稍多一些，在系統中主要體現在兩個線程上面。一個是負責從Master請求和接收binary日志，並寫入本地relay log中的I/O線程。另外一個是負責從realy 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 的關系圖：
