主頁 > 知識庫 > MySQL InnoDB架構(gòu)的相關(guān)總結(jié)

MySQL InnoDB架構(gòu)的相關(guān)總結(jié)

熱門標(biāo)簽:服務(wù)外包 百度競價排名 網(wǎng)站排名優(yōu)化 AI電銷 Linux服務(wù)器 地方門戶網(wǎng)站 呼叫中心市場需求 鐵路電話系統(tǒng)

引言

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

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

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

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

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

SQL接口

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

解析器

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

優(yōu)化器

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

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

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

執(zhí)行器

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

存儲引擎

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

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

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

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

內(nèi)存緩沖池

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

undo log日志文件

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

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

redolog日志文件

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

binlog日志文件

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

InnoDB執(zhí)行流程

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

  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用于故障恢復(fù)數(shù)據(jù);
  5. 準(zhǔn)備提交事務(wù),redo log日志基于策略準(zhǔn)備刷入磁盤;
  6. 準(zhǔn)備提交事務(wù),binlog日志基于策略準(zhǔn)備刷入磁盤;
  7. 寫入binlog文件與commit標(biāo)記到redo log日志文件;
  8. 提交事務(wù);
  9. 后臺IO線程將Buffer Pool中臟數(shù)據(jù)輸入磁盤。(因為前期只修改了Buffer Pool中日志,磁盤中數(shù)據(jù)并未修改,所以對于磁盤數(shù)據(jù)來說,Buffer Pool中的數(shù)據(jù)是臟數(shù)據(jù))

流程如下圖所示:

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

您可能感興趣的文章:
  • MySQL InnoDB ReplicaSet(副本集)簡單介紹
  • 詳解MySQL InnoDB存儲引擎的內(nèi)存管理
  • MySQL Innodb關(guān)鍵特性之插入緩沖(insert buffer)
  • MySQL InnoDB 鎖的相關(guān)總結(jié)
  • 如何區(qū)分MySQL的innodb_flush_log_at_trx_commit和sync_binlog
  • Mysql InnoDB的鎖定機制實例詳解
  • Mysql技術(shù)內(nèi)幕之InnoDB鎖的深入講解
  • 修改MySQL數(shù)據(jù)庫引擎為InnoDB的操作
  • 簡述MySQL InnoDB存儲引擎
  • MySQL InnoDB表空間加密示例詳解
  • MySQL InnoDB 事務(wù)鎖源碼分析

標(biāo)簽:湘潭 湖南 崇左 蘭州 仙桃 銅川 衡水 黃山

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL InnoDB架構(gòu)的相關(guān)總結(jié)》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266