系統(tǒng)只要能從數(shù)據(jù)庫(kù)連接池獲取到一個(gè)數(shù)據(jù)庫(kù)連接，就能執(zhí)行CRUD?？赏ㄟ^(guò)數(shù)據(jù)庫(kù)連接將待執(zhí)行SQL發(fā)給MySQL。

大部分 crud boy只知道：

• 執(zhí)行insert語(yǔ)句后，在表里會(huì)多條數(shù)據(jù)
• 執(zhí)行update后，會(huì)更改表數(shù)據(jù)
• 執(zhí)行delete后，會(huì)刪除表里數(shù)據(jù)
• 執(zhí)行select后，會(huì)查詢表里數(shù)據(jù)出來(lái)
• 要是SQL性能丟人，建幾個(gè)索引解決
• …

這應(yīng)該是目前行業(yè)內(nèi)很多工程師對(duì)數(shù)據(jù)庫(kù)的一個(gè)認(rèn)知，完全當(dāng)他是個(gè)黑盒來(lái)建表及執(zhí)行SQL。

網(wǎng)絡(luò)連接必須有線程處理

假設(shè)數(shù)據(jù)庫(kù)服務(wù)器的連接池中的某個(gè)連接，接收到一條SQL網(wǎng)絡(luò)請(qǐng)求，請(qǐng)思考：

• 誰(shuí)負(fù)責(zé)從這個(gè)連接中去監(jiān)聽(tīng)網(wǎng)絡(luò)請(qǐng)求？
• 誰(shuí)負(fù)責(zé)從網(wǎng)絡(luò)連接里把請(qǐng)求數(shù)據(jù)讀取出來(lái)？

網(wǎng)絡(luò)連接得有一個(gè)線程來(lái)監(jiān)聽(tīng)請(qǐng)求及讀取請(qǐng)求數(shù)據(jù)，比如從網(wǎng)絡(luò)連接中讀取和解析出來(lái)一條業(yè)務(wù)系統(tǒng)發(fā)的SQL語(yǔ)句：

SQL接口

負(fù)責(zé)處理接收到的SQL語(yǔ)句。

MySQL的工作線程從一個(gè)網(wǎng)絡(luò)連接中讀出一個(gè)SQL語(yǔ)句后，會(huì)如何執(zhí)行該SQL呢？

MySQL提供了SQL接口（SQL Interface），一套執(zhí)行SQL語(yǔ)句的接口，專門(mén)執(zhí)行業(yè)務(wù)系統(tǒng)發(fā)送的那些CRUD語(yǔ)句

因此MySQL的工作線程接收到SQL語(yǔ)句之后，就會(huì)轉(zhuǎn)交給SQL接口去執(zhí)行：

查詢解析器

那SQL接口怎么執(zhí)行SQL語(yǔ)句的？這玩意能懂這些SQL語(yǔ)句？

假設(shè)有如下SQL：

select id,name,age from users where id=1

這就需要查詢解析器（Parser），負(fù)責(zé)解析SQL語(yǔ)句，比如對(duì)那個(gè)SQL拆解成：

• 要從“users”表里查詢數(shù)據(jù)
• 查詢“id”字段的值等于1的那行數(shù)據(jù)
• 對(duì)查出來(lái)的那行數(shù)據(jù)要提取里面的“id,name,age”三字段

SQL解析也就是按SQL語(yǔ)法來(lái)解析SQL語(yǔ)句意欲何為：

查詢優(yōu)化器

通過(guò)解析器知道SQL要干啥了，然后就得找查詢優(yōu)化器（Optimizer）選擇一個(gè)最優(yōu)查詢路徑。

啥叫最優(yōu)查詢路徑呢？

之前的那個(gè)SQL：從“users”表里查詢數(shù)據(jù)，查“id”字段的值等于1的那行數(shù)據(jù)，對(duì)查出來(lái)的那行數(shù)據(jù)要提取里面的“id,name,age”三個(gè)字段。

要完成此事有如下查詢路徑：

• 直接定位到users表中的id字段等于1的那行數(shù)據(jù)，查出來(lái)那行數(shù)據(jù)的id、name、age三個(gè)字段值
• 先把users表中的每行數(shù)據(jù)的“id,name,age”三個(gè)字段的值都查出來(lái)，然后從這批數(shù)據(jù)里過(guò)濾出來(lái)“id”字段等于1的那行數(shù)據(jù)的“id,name,age”三個(gè)字段

可見(jiàn)，完成該SQL，兩條路徑都能實(shí)現(xiàn)，那到底選哪個(gè)呢？顯然第一種性能更好。

所以查詢優(yōu)化器大概就是這個(gè)意義，他會(huì)針對(duì)你的SQL生成查詢路徑樹(shù)，選擇最優(yōu)查詢路徑。

調(diào)用存儲(chǔ)引擎接口，真正執(zhí)行SQL語(yǔ)句。

把查詢優(yōu)化器選擇的最優(yōu)查詢路徑，即到底應(yīng)該按照一個(gè)什么樣的順序和步驟去執(zhí)行這個(gè)SQL語(yǔ)句的計(jì)劃，把該計(jì)劃交給底層的存儲(chǔ)引擎去真正執(zhí)行。

假設(shè)我們的數(shù)據(jù)有的存在內(nèi)存，有的存在磁盤(pán)文件，那到底怎么知道

• 哪些數(shù)據(jù)在內(nèi)存？
• 哪些在磁盤(pán)？

執(zhí)行時(shí)：

• 是更新內(nèi)存數(shù)據(jù)？
• 還是更新磁盤(pán)數(shù)據(jù)？

若更新磁盤(pán)數(shù)據(jù)：

• 先查詢哪個(gè)磁盤(pán)文件
• 再更新哪個(gè)磁盤(pán)文件？

這就需要存儲(chǔ)引擎，就是個(gè)執(zhí)行SQL語(yǔ)句的，會(huì)按步驟查詢內(nèi)存緩存數(shù)據(jù)，更新磁盤(pán)數(shù) 據(jù)，查詢磁盤(pán)數(shù)據(jù)等，執(zhí)行此類的一系列的操作：

MySQL架構(gòu)設(shè)計(jì)中，SQL接口、SQL解析器、查詢優(yōu)化器都是通用的，屬于一套組件。但支持各種存儲(chǔ)引擎，如InnoDB、MyISAM、Memory等，可以選擇具體使用哪種存儲(chǔ)引擎來(lái)負(fù)責(zé)執(zhí)行SQL。

執(zhí)行器

根據(jù)執(zhí)行計(jì)劃調(diào)用存儲(chǔ)引擎的接口。

存儲(chǔ)引擎可幫助我們?nèi)ピL問(wèn)內(nèi)存及磁盤(pán)上的數(shù)據(jù)，那誰(shuí)來(lái)調(diào)存儲(chǔ)引擎的接口？

那就是執(zhí)行器，會(huì)根據(jù)優(yōu)化器選擇的執(zhí)行方案，按照一定的順序和步驟調(diào)用存儲(chǔ)引擎的接口，執(zhí)行SQL邏輯。

比如執(zhí)行器可能先調(diào)用存儲(chǔ)引擎的一個(gè)接口，獲取“users”表中的第一行數(shù)據(jù)，然后判斷一下這個(gè)數(shù)據(jù)的“id”字段的值是否等于我們期望的一個(gè)值，如果不是的話，那就繼續(xù)調(diào)用存儲(chǔ)引擎的接口，去獲取“users”表的下一行數(shù)據(jù)。

也就這套操作，執(zhí)行器會(huì)根據(jù)優(yōu)化器生成的執(zhí)行計(jì)劃，不停調(diào)用存儲(chǔ)引擎的接口們，去完成SQL語(yǔ)句的執(zhí)行計(jì)劃，即不停的更新或提取一些數(shù)據(jù)：

到此這篇關(guān)于MySQL通透詳解架構(gòu)設(shè)計(jì)的文章就介紹到這了,更多相關(guān)MySQL 架構(gòu)設(shè)計(jì)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論