目錄
- 引言
- 1、Mysql數(shù)據(jù)庫整體架構(gòu)
- SQL接口
- 解析器
- 優(yōu)化器
- 執(zhí)行器
- 存儲引擎
- 2、InnoDB存儲引擎架構(gòu)
- 內(nèi)存緩沖池
- undo log日志文件
- redolog日志文件
- binlog日志文件
- InnoDB執(zhí)行流程
引言
作為一個后端程序員,我們幾乎每天都要和數(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來管理項(xiàng)目的話,一般會看到如下配置:
dependency>
groupId>mysql/groupId>
artifactId>mysql-connector-java/artifactId>
version>8.0.24/version>
/dependency>
如上,通過maven導(dǎo)MySQL的驅(qū)動jar包,接著就可以在項(xiàng)目中通過sql語句操作數(shù)據(jù)庫了。那數(shù)據(jù)庫在接收到請求后,是怎么執(zhí)行的呢?接下來我將通過MySQL數(shù)據(jù)庫進(jìn)行詳細(xì)闡述。
1、Mysql數(shù)據(jù)庫整體架構(gòu)
一般我們知道,web項(xiàng)目開發(fā)完以后,可以將項(xiàng)目文件打成一個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的值,至少可以有以下兩種路徑:
- 先去表T中篩選出符合條件C的所有數(shù)據(jù)行,再選出字段f1,f2的值作為結(jié)果集;
- 先選出所有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í)行計(jì)劃,然后不停的去調(diào)用數(shù)據(jù)庫存儲引擎提供的接口去完成SQL語句的執(zhí)行計(jì)劃。
存儲引擎
數(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來實(shí)現(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宕機(jī)了,那么必然會使內(nèi)存中修改過的數(shù)據(jù)丟失。為了解決這個問題InnoDB架構(gòu)中設(shè)計(jì)了redo log,用來記錄你對什么數(shù)據(jù)進(jìn)行了修改。如果出現(xiàn)MySQL宕機(jī),重啟之后可以通過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ù)某個時間點(diǎn)的數(shù)據(jù),主從同步等,而redo log用戶故障恢復(fù)。一般提交事務(wù)的時候也會提交歸檔日志。同樣的歸檔日志也有幾種刷盤策略,通過sync_binlog來控制幾次事務(wù)提交后會刷盤。特別的sync_binlog=0表示由操作系統(tǒng)控制刷盤時機(jī),而不是Mysql。
InnoDB執(zhí)行流程
介紹完InnoDB存儲引擎的幾個組件后,假設(shè)現(xiàn)在需要更新一條數(shù)據(jù),那么在InnoDB中的執(zhí)行流程應(yīng)該是怎么樣的呢?如下:
- 如果數(shù)據(jù)不存在于Buffer Pool中,則隨機(jī)I/O從磁盤讀取數(shù)據(jù),放入Buffer Pool;
- 寫undo log用于回滾數(shù)據(jù);
- 更新Buffer Pool中的數(shù)據(jù);
- 寫redo log到redo log buffer用于故障恢復(fù)數(shù)據(jù);
- 準(zhǔn)備提交事務(wù),redo log日志基于策略準(zhǔn)備刷入磁盤;
- 準(zhǔn)備提交事務(wù),binlog日志基于策略準(zhǔn)備刷入磁盤;
- 寫入binlog文件與commit標(biāo)記到redo log日志文件;
- 提交事務(wù);
- 后臺IO線程將Buffer Pool中臟數(shù)據(jù)輸入磁盤。(因?yàn)榍捌谥恍薷牧薆uffer 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的鎖定機(jī)制實(shí)例詳解
- Mysql技術(shù)內(nèi)幕之InnoDB鎖的深入講解
- 修改MySQL數(shù)據(jù)庫引擎為InnoDB的操作
- 簡述MySQL InnoDB存儲引擎
- MySQL InnoDB表空間加密示例詳解
- MySQL InnoDB 事務(wù)鎖源碼分析