引言

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

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

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

1、Mysql數(shù)據(jù)庫整體架構

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

SQL接口

當請求到達數(shù)據(jù)庫以后，會被監(jiān)聽的線程發(fā)現(xiàn)，繼而將請求轉交給SQL接口來處理，SQL接口專門用于執(zhí)行增刪改查這樣的SQL語句。

解析器

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

優(yōu)化器

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

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

優(yōu)化器會根據(jù)不同的策略得到它認為最優(yōu)的查詢路徑。

執(zhí)行器

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

存儲引擎

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

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

2、InnoDB存儲引擎架構

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

內存緩沖池

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

undo log日志文件

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

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

redolog日志文件

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

binlog日志文件

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

InnoDB執(zhí)行流程

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

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

流程如下圖所示：

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

最新評論