1.Mysql的邏輯架構(gòu)

Mysql的邏輯架構(gòu)如下所示，整體分為兩部分，Server層和存儲(chǔ)引擎層。

與存儲(chǔ)引擎無(wú)關(guān)的操作都是在Server層完成的，存儲(chǔ)引擎層負(fù)責(zé)數(shù)據(jù)的存取。

下面將會(huì)按照上圖的過(guò)程分別介紹每一步的作用，這里以查詢一條記錄為例。

2.連接器

這一步主要是管理連接和權(quán)限驗(yàn)證。

負(fù)責(zé)管理客戶端的連接，比如mysql -u root -p，就是客戶端與連接器之間完成的，連接分為長(zhǎng)連接和短連接，建議使用長(zhǎng)連接，因?yàn)榻⑦B接是相對(duì)復(fù)雜的一個(gè)過(guò)程。但是長(zhǎng)連接也有優(yōu)化的空間，即長(zhǎng)連接過(guò)多，隨著執(zhí)行大的查詢操作，會(huì)占用較多的內(nèi)存。

建立連接完成之后，連接器會(huì)判斷該用戶的權(quán)限，之后用戶的操作都會(huì)基于權(quán)限來(lái)判定是否允許。

3.分析器

這一步主要是詞法分析和語(yǔ)法分析。

詞法分析主要是判定用戶想做什么，比如select 就是想要查詢。

語(yǔ)法分析主要是判定用戶輸入的SQL是否符合Mysql的語(yǔ)法。

4.優(yōu)化器

經(jīng)過(guò)分析器，Mysql已經(jīng)知道用戶想要干什么了，但是對(duì)于相同的一條SQL語(yǔ)句，對(duì)于Mysql具體實(shí)施的時(shí)候，可能有多種方法去實(shí)現(xiàn)，效率也就不一樣。

在優(yōu)化器這一步，mysql需要判定怎么樣執(zhí)行才是最優(yōu)的效率。

5.執(zhí)行器

這一步主要是操作引擎和返回結(jié)果。通過(guò)操作存儲(chǔ)引擎層來(lái)遍歷一張數(shù)據(jù)表，去尋找符合條件的數(shù)據(jù)，并且返回給客戶端。

6.Mysql執(zhí)行一條更新語(yǔ)句的過(guò)程

與一條SQL查詢語(yǔ)句相同的是，在Mysql中同樣要經(jīng)過(guò)連接器、分析器、優(yōu)化器、執(zhí)行器，也要用到存儲(chǔ)引擎來(lái)進(jìn)行數(shù)據(jù)的存取。

不同的是，更新語(yǔ)句需要涉及到兩個(gè)重要的日志模塊，redo log和binlog

7.redo log

一家飯店生意紅火，但作為一家飯店來(lái)說(shuō)，免不了每天都有賒賬和來(lái)還賬的。

如果賒賬和還賬的人不多還好，老板可以直接用一塊粉板來(lái)記錄，如果人多，粉板根本寫(xiě)不下一個(gè)月的賒賬記錄。

所以老板想到可以把所有的賒賬記錄寫(xiě)到賬本上，而粉板上寫(xiě)的都是短時(shí)間的，等下班了之后，拿粉板上的和賬本進(jìn)行對(duì)賬。

在這個(gè)例子中，粉板就是redo log，賬本就是mysql中的記錄，我們用還賬類比一下mysql的更新過(guò)程，如果每次有人更新，我們都去mysql中找到這條記錄，效率很低，所以mysql的思路和這個(gè)老板一致，更新操作先放到redo log中，過(guò)一段時(shí)間再慢慢消化。

這種思路叫WAL技術(shù)，即Write Ahead Logging技術(shù)，先寫(xiě)日志，再寫(xiě)磁盤(pán)。

需要注意的是，粉板如果滿了，老板還沒(méi)下班，老板就必須停下來(lái)手中的活。mysql中的redo log總共可以記錄4GB的操作

當(dāng)write pos 追上check point，mysql這個(gè)老板就要去處理一下redo log了。

除此之外，有了redo log持久化，數(shù)據(jù)庫(kù)即使異常重啟也不會(huì)丟日志，這是crash safe機(jī)制，但仍需要注意的是，redo log是innodb存儲(chǔ)引擎特有的。

8.bin log

binlog是Server層的日志，可以適用于所有存儲(chǔ)引擎。

那既然有binlog了，前文為什么要搞一個(gè)innodb存儲(chǔ)引擎專屬的redo log呢？

因?yàn)閙ysql最開(kāi)始沒(méi)有innodb引擎，而是myisam引擎，使用的是binlog，但是binlog僅限于歸檔，沒(méi)有crash safe機(jī)制，于是自己補(bǔ)充了一個(gè)redo log。

• redo log是innodb存儲(chǔ)引擎特有的，而binlog是server層特有的
• redo log存儲(chǔ)的是物理日志，binlog是邏輯日志
• redo log像上面講的那樣，支持4GB大小，多了就得處理并且去覆蓋，binlog日志當(dāng)寫(xiě)滿一個(gè)日志

文件之后，會(huì)新建一個(gè)新的日志文件。

下面以更新ID為2的一行數(shù)據(jù)為例：

圖中淺色框表示是在 InnoDB 內(nèi)部執(zhí)行的，深色框表示是在執(zhí)行器中執(zhí)行的。

• 執(zhí)行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹(shù)搜索找到這一行。如果 ID=2 這一行所在的數(shù)據(jù)頁(yè)本來(lái)就在內(nèi)存中，就直接返回給執(zhí)行器；否則，需要先從磁盤(pán)讀入內(nèi)存，然后再返回。
• 執(zhí)行器拿到引擎給的行數(shù)據(jù)，把這個(gè)值加上 1，比如原來(lái)是 N，現(xiàn)在就是 N+1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫(xiě)入這行新數(shù)據(jù)。
• 引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個(gè)更新操作記錄到 redo log 里面，此時(shí) redo log 處于 prepare 狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時(shí)可以提交事務(wù)。執(zhí)行器生成這個(gè)操作的 binlog，并把 binlog 寫(xiě)入磁盤(pán)。
• 執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫(xiě)入的 redo log 改成提交（commit）狀態(tài)，更新完成。

 到此這篇關(guān)于Mysql 執(zhí)行一條語(yǔ)句的整個(gè)過(guò)程詳細(xì)的文章就介紹到這了,更多相關(guān)Mysql 執(zhí)行一條語(yǔ)句的過(guò)程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論