首先先簡單的將一個(gè)查詢語句背后MySQL做了什么捋一捋：

• 客戶端發(fā)送一條查詢給服務(wù)器。
• 服務(wù)器先檢查查詢緩存，如果命中了緩存，則立刻返回存儲在緩存中的結(jié)果。否則進(jìn)入下一個(gè)階段。
• 服務(wù)器端進(jìn)行SQL解析，預(yù)處理，再由優(yōu)化器生成對應(yīng)的執(zhí)行計(jì)劃。
• MySQL根據(jù)優(yōu)化器生成的執(zhí)行計(jì)劃，調(diào)用存儲引擎的API來執(zhí)行查詢。
• 將結(jié)果返回給客戶端。

接著我們就將這個(gè)過程中的這些步驟詳細(xì)的進(jìn)行展開。

1.客戶端和服務(wù)器端之間的通信方式

客戶端和服務(wù)器之間的通信是一種半雙工的通信，即在同一時(shí)刻，只能有一方向另一方發(fā)送數(shù)據(jù)。所以客戶端在發(fā)送完查詢請求之后，所能做的就是等待服務(wù)器將查詢的結(jié)果返回，并且需要一直地等到返回的數(shù)據(jù)全部接收完畢后才能進(jìn)行下一步的操作，而不可以在服務(wù)器發(fā)送的過程中中斷發(fā)送或者斷開連接。

2.查詢緩存

在解析一個(gè)查詢語句之前，如果查詢緩存是打開著的，那么MySQL會優(yōu)先檢查這個(gè)查詢是否命中查詢緩存中的數(shù)據(jù)。這個(gè)檢查是通過一個(gè)對大小寫敏感的哈希表來實(shí)現(xiàn)的。在查詢命中緩存的情況下，直接從緩存中拿到結(jié)果并返回給客戶端。MySQL不會再執(zhí)行下面的操作，即查詢語句不會被解析，不會生成執(zhí)行計(jì)劃，不會被執(zhí)行。

3.查詢優(yōu)化處理

這個(gè)環(huán)節(jié)可能是整個(gè)查詢執(zhí)行過程中最為復(fù)雜的一個(gè)環(huán)節(jié)，可以分為解析SQL，預(yù)處理和優(yōu)化SQL執(zhí)行計(jì)劃三個(gè)步驟。

（1）語法解析器和預(yù)處理
這個(gè)過程就是對我們傳入的SQL語句的語法進(jìn)行檢查，以及驗(yàn)證查詢的權(quán)限。炳輝生成一棵“解析樹”。

（2）查詢優(yōu)化器
在進(jìn)入到這一步時(shí)，證明我們的語句語法層面已經(jīng)沒有問題了。一條查詢可以有很多種執(zhí)行計(jì)劃都能返回正確的結(jié)果，這個(gè)環(huán)節(jié)就是來選取最優(yōu)的執(zhí)行計(jì)劃的。
MySQL的最優(yōu)執(zhí)行計(jì)劃是基于成本的。MySQL會為每個(gè)操作設(shè)定一個(gè)成本（如執(zhí)行一次where比較），并從所有的執(zhí)行計(jì)劃中選擇“成本”最少的。
我們可以使用下列語句查看上一個(gè)查詢操作的成本：

mysql> SHOW STATUS LIKE 'last_query_cost';

MySQL會返回一個(gè)執(zhí)行的成本數(shù)據(jù)：

+-----------------+----------+
| Variable_name  | Value  |
+-----------------+----------+
| Last_query_cost | 0.549000 |
+-----------------+----------+

但值得注意的是，這里的“成本”最小并不等于查詢的速度最快。即以“成本”來判斷查詢語句的優(yōu)劣有時(shí)候是不可靠的。

優(yōu)化器的優(yōu)化策略可以大致地分為兩種：靜態(tài)優(yōu)化和動(dòng)態(tài)優(yōu)化。

靜態(tài)優(yōu)化是直接對之前生成的解析樹進(jìn)行分析，例如可以通過一些代數(shù)變換將where條件轉(zhuǎn)化為另一種等價(jià)形式。靜態(tài)優(yōu)化在第一次完成后就一直生效，即使使用不同的參數(shù)重復(fù)執(zhí)行查詢也不會發(fā)生變化，可以認(rèn)為是一種“編譯（預(yù)處理）時(shí)優(yōu)化”。

動(dòng)態(tài)優(yōu)化和查詢的上下文相關(guān)，需要在每一次查詢的時(shí)候重新評估，可以認(rèn)為是一種“運(yùn)行時(shí)優(yōu)化”。

下面是一些MySQL能夠處理的優(yōu)化類型：

• 重新定義關(guān)聯(lián)表的順序
  

有時(shí)候我們所給的查詢語句關(guān)聯(lián)表的順序可能對于查詢來說效率并不是最優(yōu)的，這時(shí)候MySQL可以自動(dòng)幫我們將關(guān)聯(lián)表的順序進(jìn)行調(diào)整提高效率。

• 將外連接轉(zhuǎn)化為內(nèi)連接
  

并不是所有的OUT JOIN語句都必須以外連接的方式執(zhí)行。MySQL能夠識別這一點(diǎn)并重寫查詢，讓其可以調(diào)整關(guān)聯(lián)順序。

• 使用等價(jià)變換規(guī)則
  

使用一些等價(jià)的語句來減少比較的次數(shù)，移除一些恒成立和不恒成立的條件。例如，（5=5 AND a>5）會被改寫為a>5;如果有(a5 AND b=c AND a=5。

• 優(yōu)化COUNT()、MIN()和MAX()
  

索引和列是否為空可以幫助優(yōu)化這一類表達(dá)式。例如查找最小值的時(shí)候就可以借助索引直接查找最左端的記錄，這樣就不用進(jìn)行整個(gè)表的查詢，而是以一個(gè)常數(shù)進(jìn)行取代。

• 覆蓋索引掃描
  

當(dāng)索引中的列包含所有查詢中需要使用的列的時(shí)候，MySQL就會使用索引返回所需要的數(shù)據(jù)，而無須查詢對應(yīng)的數(shù)據(jù)行。

• 提前終止查詢
  

在發(fā)現(xiàn)查詢已經(jīng)能滿足需求的時(shí)候，MySQL總能立刻終止查詢。一個(gè)典型的例子就是當(dāng)使用了LIMIT子句的時(shí)候。

至此，MySQL服務(wù)器層已經(jīng)根據(jù)所給的查詢語句給出了一個(gè)最優(yōu)的執(zhí)行計(jì)劃。但是我們需要知道的是，我們到目前為止所進(jìn)行的一些列的操作都是在服務(wù)器層進(jìn)行的，而這一層中并不是數(shù)據(jù)存儲的地方。因此接下來我們需要拿著我們的最優(yōu)執(zhí)行計(jì)劃去到實(shí)際的存儲引擎中進(jìn)行查找。因此就引出了我們的下一步操作：向存儲引擎獲取相應(yīng)的統(tǒng)計(jì)信息。

4.查詢執(zhí)行引擎

相對于查詢優(yōu)化階段，查詢執(zhí)行階段并不是那么復(fù)雜。MySQL只是簡單地根據(jù)執(zhí)行計(jì)劃給出的指令逐步執(zhí)行。

5.返回結(jié)果給客戶端

查詢執(zhí)行的最后一個(gè)階段是將結(jié)果返回給客戶端，即使查詢不需要返回結(jié)果集給客戶端，MySQL仍然會返回這個(gè)查詢的一些信息，例如查詢影響的行數(shù)。
如果查詢可以被緩存，這個(gè)階段MySQL會講查詢的結(jié)果放到查詢緩存中。
返回結(jié)果的過程是一個(gè)逐步增量的過程。即當(dāng)拿到第一個(gè)結(jié)果的時(shí)候就開始向客戶端返回了。這樣做的好處是不會一次性返回全部數(shù)據(jù)導(dǎo)致占用內(nèi)存過多，而且客戶端也能在第一時(shí)間拿到結(jié)果。結(jié)果集中的每一行都會以一個(gè)滿足MySQL客戶端/服務(wù)器通信協(xié)議的封包發(fā)送，再通過TCP協(xié)議進(jìn)行傳輸，在TCP傳輸?shù)倪^程中，可能對封包進(jìn)行緩存后再批量發(fā)傳輸。

以上就是詳解MySQL 查詢語句的執(zhí)行過程的詳細(xì)內(nèi)容，更多關(guān)于MySQL 查詢語句的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論