引言

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

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

如上，通過(guò)maven導(dǎo)MySQL的驅(qū)動(dòng)jar包，接著就可以在項(xiàng)目中通過(guò)sql語(yǔ)句操作數(shù)據(jù)庫(kù)了。那數(shù)據(jù)庫(kù)在接收到請(qǐng)求后，是怎么執(zhí)行的呢？接下來(lái)我將通過(guò)MySQL數(shù)據(jù)庫(kù)進(jìn)行詳細(xì)闡述。

1、Mysql數(shù)據(jù)庫(kù)整體架構(gòu)

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

SQL接口

當(dāng)請(qǐng)求到達(dá)數(shù)據(jù)庫(kù)以后，會(huì)被監(jiān)聽(tīng)的線程發(fā)現(xiàn)，繼而將請(qǐng)求轉(zhuǎn)交給SQL接口來(lái)處理，SQL接口專門用于執(zhí)行增刪改查這樣的SQL語(yǔ)句。

解析器

雖然SQL語(yǔ)句我們比較容易理解，但是對(duì)于MySQL系統(tǒng)來(lái)說(shuō)是沒(méi)法直接理解的，所以SQL接口會(huì)把SQL語(yǔ)句轉(zhuǎn)交給解析器，查詢解析器負(fù)責(zé)將SQL語(yǔ)句進(jìn)行解析，也就是按照既定的SQL語(yǔ)法，對(duì)SQL語(yǔ)句進(jìn)行解析，理解這個(gè)SQL要完成的操作。

優(yōu)化器

當(dāng)解析器理解了SQL語(yǔ)句需要完成的操作后，接著通過(guò)優(yōu)化器選擇一條它認(rèn)為的最優(yōu)路徑。一般情況下，要達(dá)到某種結(jié)果并不是只有一條路徑，比如，要查詢?cè)诒鞹里，符合條件C的兩個(gè)字段f1,f2的值，至少可以有以下兩種路徑：

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

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

執(zhí)行器

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

存儲(chǔ)引擎

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

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

2、InnoDB存儲(chǔ)引擎架構(gòu)

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

內(nèi)存緩沖池

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

undo log日志文件

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

一般MySQL數(shù)據(jù)庫(kù)會(huì)默認(rèn)開(kāi)啟事務(wù)自動(dòng)提交，所以不需要我們做額外的操作，我們可以通過(guò)set autocommit = 0 來(lái)關(guān)閉自動(dòng)提交事務(wù)和set autocommit來(lái)打開(kāi)自動(dòng)提交事務(wù)。有興趣可以試試去感受感受。

redolog日志文件

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

binlog日志文件

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

InnoDB執(zhí)行流程

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

1. 如果數(shù)據(jù)不存在于Buffer Pool中，則隨機(jī)I/O從磁盤(pán)讀取數(shù)據(jù)，放入Buffer Pool;
2. 寫(xiě)undo log用于回滾數(shù)據(jù)；
3. 更新Buffer Pool中的數(shù)據(jù)；
4. 寫(xiě)redo log到redo log buffer用于故障恢復(fù)數(shù)據(jù)；
5. 準(zhǔn)備提交事務(wù)，redo log日志基于策略準(zhǔn)備刷入磁盤(pán)；
6. 準(zhǔn)備提交事務(wù)，binlog日志基于策略準(zhǔn)備刷入磁盤(pán)；
7. 寫(xiě)入binlog文件與commit標(biāo)記到redo log日志文件；
8. 提交事務(wù)；
9. 后臺(tái)IO線程將Buffer Pool中臟數(shù)據(jù)輸入磁盤(pán)。（因?yàn)榍捌谥恍薷牧薆uffer Pool中日志，磁盤(pán)中數(shù)據(jù)并未修改，所以對(duì)于磁盤(pán)數(shù)據(jù)來(lái)說(shuō)，Buffer Pool中的數(shù)據(jù)是臟數(shù)據(jù)）
   

流程如下圖所示：

以上就是MySQL InnoDB架構(gòu)的相關(guān)總結(jié)的詳細(xì)內(nèi)容，更多關(guān)于MySQL InnoDB架構(gòu)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論