引言

作為一個后端程序員，我們幾乎每天都要和數據庫打交道，市面上的數據庫有很多，比如：Mysql，Oracle，SqlServer等等，那么我們的寫的程序是怎么和數據庫連接起來的呢？那就是數據庫驅動，不同的數據庫對應了不同的數據庫驅動。在我們連接數據庫的時候，首先將數據庫驅動進行注冊，然后基于數據庫地址，用戶名，密碼等信息與數據庫建立連接。如果用maven來管理項目的話，一般會看到如下配置：

dependency>
  groupId>mysql/groupId>
  artifactId>mysql-connector-java/artifactId>
  version>8.0.24/version>
/dependency>

如上，通過maven導MySQL的驅動jar包，接著就可以在項目中通過sql語句操作數據庫了。那數據庫在接收到請求后，是怎么執行的呢？接下來我將通過MySQL數據庫進行詳細闡述。

1、Mysql數據庫整體架構

一般我們知道，web項目開發完以后，可以將項目文件打成一個war包，然后通過Tomcat容器進行發布，最后用戶就可以訪問我們的系統了。我們都知道，Tomcat是支持并發訪問的，當多個請求需要同時操作數據庫的時候，難道是多個請求去搶占一個數據庫連接嗎？那肯定不是的，不然效率得多低下，那難道是給每個請求都建立一個連接，請求結束后再銷毀連接嗎？那肯定也不是的，頻繁建立、銷毀連接肯定也是影響性能的。那Tomcat是如何解決這個問題的呢？ 還記得我們在講線程池的時候提到的“池化”思想嗎？是的，Tomcat中有一個數據庫連接池，那么同樣的數據庫服務器中也有一個對應的數據庫連接池，大致結構如下圖所示

SQL接口

當請求到達數據庫以后，會被監聽的線程發現，繼而將請求轉交給SQL接口來處理，SQL接口專門用于執行增刪改查這樣的SQL語句。

解析器

雖然SQL語句我們比較容易理解，但是對于MySQL系統來說是沒法直接理解的，所以SQL接口會把SQL語句轉交給解析器，查詢解析器負責將SQL語句進行解析，也就是按照既定的SQL語法，對SQL語句進行解析，理解這個SQL要完成的操作。

優化器

當解析器理解了SQL語句需要完成的操作后，接著通過優化器選擇一條它認為的最優路徑。一般情況下，要達到某種結果并不是只有一條路徑，比如，要查詢在表T里，符合條件C的兩個字段f1,f2的值，至少可以有以下兩種路徑：

1. 先去表T中篩選出符合條件C的所有數據行，再選出字段f1,f2的值作為結果集；
2. 先選出所有f1,f2的值，再根據條件C篩選出符合條件的數據行組成結果集。
   

優化器會根據不同的策略得到它認為最優的查詢路徑。

執行器

當優化器選出最優的查詢路徑后，并不能得到我們最終希望得到的結果，所以還需要用執行器。執行器的作用就是根據優化器選出的最優查詢路徑生成一套執行計劃，然后不停的去調用數據庫存儲引擎提供的接口去完成SQL語句的執行計劃。

存儲引擎

數據庫一般將數據無非存儲在兩個地方：內存或磁盤。那么假如我們查詢數據時，執行器需要到去磁盤還是內存中查詢呢？內存中是如何查詢的？磁盤中是如何查詢的，內存的容量是有限的，當內存中沒有多余的空間怎么辦？等等一系列問題的解決方案就是存儲引擎，MySQL提供了多種存儲引擎：InnoDB,MyISAM,MEMORY等等，比較常見的是InnoDB和MyISAM，可以通過show engines命令查看當前MySQL數據庫的存儲引擎。本系列將主要分析InnoDB存儲引擎。

綜上，一套完整的SQL語句執行流程如下圖所示

2、InnoDB存儲引擎架構

假如現在一條SQL語句通過上述的流程，到了執行器調用InnoDB存儲引擎的接口，那么InnoDB存儲引擎是怎么工作的呢？

內存緩沖池

首先介紹InnoDB存儲引擎中第一個重要組件—內存緩沖池，即Buffer Pool，這是內存中的一塊區域，存儲了大量數據，便于執行查詢、更新等操作。這樣做的目的就是提高SQL語句的執行效率，所以要明確一個概念，我們的查詢、更新等操作都是在Buffer Pool中完成（無論數據是否存在于Buffer Pool中，存在的話直接操作，不存在的話先從磁盤中加載到Buffer Pool中再操作）。

undo log日志文件

熟悉數據庫的同學都知道，在我們更新數據的時候一般是放在一個事務中進行操作。事務有4大特性：ACID，其中A就代表了原子性，即這次操作要么全部成功要么全部失敗，成功的話就提交（commit）事務，失敗就回滾（rollback），其中回滾就是通過undo log來實現的。（有一次被問到了，一時緊張沒想起來，過了一會才反應過來...）。

一般MySQL數據庫會默認開啟事務自動提交，所以不需要我們做額外的操作，我們可以通過set autocommit = 0 來關閉自動提交事務和set autocommit來打開自動提交事務。有興趣可以試試去感受感受。

redolog日志文件

前面我們已經介紹了，更新操作是在Buffer Pool中完成的，也就是在內存中完成的，萬一操作完以后MySQL宕機了，那么必然會使內存中修改過的數據丟失。為了解決這個問題InnoDB架構中設計了redo log，用來記錄你對什么數據進行了修改。如果出現MySQL宕機，重啟之后可以通過redo log來進行數據恢復。但是redo log也是先將redo log寫到內存中的redo log buffer中，并沒有持久化到磁盤，所以數據丟失的風險依然存在。所以InnoDB提供了幾種redo log刷盤策略，通過innodb_flush_log_at_trx_commit來進行設置刷盤策略，比如innodb_flush_log_at_trx_commit=1表示事務提交日志馬上刷入磁盤，這樣就不會存在數據丟失的風險，但是性能肯定會受到影響。一般可以根據業務需求進行設置策略。

binlog日志文件

binlog也叫歸檔日志，與redo log不同，這是mysql server的，而不是InnoDB所特有的，一般用戶恢復某個時間點的數據，主從同步等，而redo log用戶故障恢復。一般提交事務的時候也會提交歸檔日志。同樣的歸檔日志也有幾種刷盤策略，通過sync_binlog來控制幾次事務提交后會刷盤。特別的sync_binlog=0表示由操作系統控制刷盤時機，而不是Mysql。

InnoDB執行流程

介紹完InnoDB存儲引擎的幾個組件后，假設現在需要更新一條數據，那么在InnoDB中的執行流程應該是怎么樣的呢？如下：

1. 如果數據不存在于Buffer Pool中，則隨機I/O從磁盤讀取數據，放入Buffer Pool;
2. 寫undo log用于回滾數據；
3. 更新Buffer Pool中的數據；
4. 寫redo log到redo log buffer用于故障恢復數據；
5. 準備提交事務，redo log日志基于策略準備刷入磁盤；
6. 準備提交事務，binlog日志基于策略準備刷入磁盤；
7. 寫入binlog文件與commit標記到redo log日志文件；
8. 提交事務；
9. 后臺IO線程將Buffer Pool中臟數據輸入磁盤。（因為前期只修改了Buffer Pool中日志，磁盤中數據并未修改，所以對于磁盤數據來說，Buffer Pool中的數據是臟數據）
   

流程如下圖所示：

以上就是MySQL InnoDB架構的相關總結的詳細內容，更多關于MySQL InnoDB架構的資料請關注腳本之家其它相關文章！