整體來講MySQL可以看成是二層架構，第一層我們通常叫做SQL Layer，在MySQL數據庫系統處理底層數據之前的所有工作都是在這一層完成的，包括但不限於：權限判斷、sql解析、執行計劃優化、query cache的處理等等；第二層就是存儲引擎層，我們通常叫做Storage Engine Layer即底層數據存取操作實現部分，由多種存儲引擎共同組成。
SQL Layer
1、初始化模塊
初始化模塊就是在MySQL Server啓動的時候，對整個系統做各種各樣的初始化操作，各種系統變量的初始化設定，各種存儲引擎的初始化設置等。
2、核心API
核心API模塊主要是爲了提供一些需要非常高效的底層操作功能的優化實現，包括：各種底層數據結構的實現、特殊算法的實現、字符串處理、數字處理、小文件I/O、格式化輸出、最重要的內存管理等。
3、網絡交互模塊
網絡交互模塊抽象出底層網絡交互所使用的接口API，實現底層網絡數據的接收與發送來方便其他各個模塊調用，以及對這一部分的維護。
4、Client & Server交互協議模塊
任何C/S結構的軟件系統，都肯定會有自己獨有的信息交互協議，MySQL的Client & Server交互協議模塊部分，實現了客戶端與MySQL交互過程中的所有協議。這些協議都是建立在現有的OS和網絡協議之上的，如TCP/IP以及Unix Socket。
5、用戶模塊
用戶模塊所實現的功能，主要包括用戶的登錄連接、權限控制、用戶授權管理等，決定是否給來訪者“開門”。
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、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和DDL的query，如：update，delte，insert，create table，alter table 等語句的處理。
12、表維護模塊
表的狀態檢查、錯誤修復、以及優化和分析等工作都是表維護模塊需要做的事情。
13、系統狀態管理模塊
系統狀態管理模塊負責在客戶端請求系統狀態的時候，將各種狀態數據返回給用戶，像DBA常用的各種show status命令，show variables命令等，所得到的結果都是由這個模塊返回的。
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命令之後，“初始化模塊”開始工作，從系統配置文件中讀取系統參數、命令行參數，並按照參數來初始化整個系統。同時各個存儲引擎也被啓動，並進行各自的初始化工作。
第二步：“連接管理模塊”啓動處理客戶端連接請求的監聽程序，包括tcp/ip網絡監聽、unix的socket。此時MySQL Server基本啓動完成，準備好接受客戶端請求了。
第三步：當“連接管理模塊”通過“網絡交互模塊”監聽到客戶端的連接請求，雙方通過“Client & Server交互協議模塊”交互後，“連接管理模塊”將連接請求轉發給“線程管理模塊”，“線程管理模塊”又會將控制交給“連接線程模塊”。“連接線程模塊”在接到Client連接請求後，首先會檢查當前連接線程池中是否有被cache 的空閒連接線程，如果有，就取出一個和客戶端請求連接上，如果沒有空閒的連接線程，則建立一個新的連接線程與客戶端請求連接。
第四步：“連接線程模塊”首先通過調用“用戶模塊”進行授權檢查，只有客戶端請求通過了授權檢查後，他纔會將客戶端請求、負責請求的連接線程連上。
第五步：與Client建立連接之後，把Client發送過來的請求分爲2大類：query、command。這裏的query就是特指SQL語句，必須通過“Query解析和轉發模塊”才能夠被執行；Command是MySQL指令，可以直接被執行。
“Query解析和轉發模塊”先對Query進行基本的語義和語法解析，然後根據命令類型的不同，有些會直接處理，有些會分發給其他模塊來處理。
如果開啓了Full Query Logging功能，那麼“Query解析和轉發模塊”會調用“日誌記錄模塊”將請求計入日誌，不管是一個Query類型的請求還是一個command類型的請求，都會被記錄進入日誌，所以出於性能考慮，一般很少打開Full Query Logging功能。
第六步：
如果是一個Query類型的請求，會將控制權交給“Query解析和轉發模塊（特指解析模塊）”。“Query解析和轉發模塊（特指解析模塊）”首先分析看是不是一個select 類型的query，如果是，則調用查詢緩存模塊，讓它檢查該query在“Query Cache模塊”中是否已經存在。如果有，則直接將cache 中的數據返回給連接線程模塊，然後通過與客戶端的連接的線程將數據傳輸給客戶端。如果不是一個可以被cache的query類型，或者cache 中沒有該query的數據，那麼query將被繼續傳回“Query解析和轉發模塊（特指解析模塊）”，讓“Query解析和轉發模塊（特指解析模塊）”進行相應處理，再通過“Query解析和轉發模塊（特指轉發模塊）”分發給相關處理模塊。
如果“Query解析和轉發模塊（特指解析模塊）”解析結果是一條未被cache的select語句，則將控制權交給Optimizer“Query優化器模塊”。
如果是DML或者是DDL語句，則會交給“表變更管理模塊”。
如果是一些更新統計信息、檢測、修復和整理類的query則會交給“表維護模塊”去處理。其中的複製相關的query則轉交給“複製模塊”去進行相應的處理，請求狀態的query 則轉交給了“系統狀態管理模塊”。實際上“表變更管理模塊”根據所對應的處理請求的不同，是分別由insert處理器、delete處理器、update處理器、create 處理器、alter 處理器來負責不同的DML和DDL的。
第七步：insert處理器、delete處理器、update處理器、create 處理器、alter 處理器收到“Query解析和轉發模塊”分發過來的請求後，首先會通過“訪問控制模塊”檢查連接用戶是否有訪問目標表以及目標字段的權限，如果有，就會調用“表管理器模塊”請求相應的表，並獲取對應的鎖。“表管理器模塊”首先會查看該表是否已經存在於table cache 中，如果已經打開則直接進行鎖相關的處理，如果沒有在cache中，則需要再打開表文件獲取鎖，然後將打開的表交給“表變更管理模塊”。（注意這裏的：表變更管理模塊、表管理器模塊）
第八步：當“表變更管理模塊”打開表之後，就會根據該表的相關meta信息，判斷表的存儲引擎類型和其他相關信息。根據表的存儲引擎類型，提交請求給“存儲引擎接口模塊”，調用對應的存儲引擎實現模塊，進行相應處理。
對於“表變更管理模塊”而言，可見的僅是“存儲引擎接口模塊”所提供的一系列標準接口，底層存儲引擎實現模塊的具體實現，對於“表變更管理模塊”來說是透明的。他只需要調用對應的接口，並指明表類型，“存儲引擎接口模塊”會根據表類型調用正確的存儲引擎來進行相應的處理。
第九步：當一條query或者一個command處理完成之後，控制權都會交還給“連接線程模塊”。如果處理成功，則將處理結果通過“連接線程模塊”反饋給客戶端。如果處理過程中發生錯誤，也會將相應的錯誤信息發送給客戶端，然後連接線程模塊會進行相應的清理工作，並繼續等待後面的請求，重複上面提到的過程，或者完成客戶端斷開連接的請求。
最後：如果在上面的過程中，相關模塊使數據庫中的數據發生了變化，而且MySQL打開了binlog功能，則對應的處理模塊還會調用“日誌記錄模塊”將相應的變更語句以更新事件的形式記錄到相關參數指定的二進制日誌文件中。
在上面各個模塊的處理過程中，各自的核心運算處理功能部分都會高度依賴整個MySQL的“核心API”，比如內存管理、文件I/O、數字和字符串處理等等。