[[414987]]

為了理解這個(gè)問題，先從Mysql的架構(gòu)說起，對(duì)于Mysql來說，大致可以分為3層架構(gòu)。

第一層作為客戶端和服務(wù)端的連接，連接器負(fù)責(zé)處理和客戶端的連接，還有一些權(quán)限認(rèn)證之類。比如客戶端通用用戶名密碼連接到Mysql服務(wù)器，還有對(duì)于數(shù)據(jù)庫表的執(zhí)行權(quán)限。

第二層是核心層，基本上Mysql大部分的核心功能都在這一層，包括查詢緩存、解析器、優(yōu)化器之類，比如SQL解析、優(yōu)化、索引選擇，到最后生成執(zhí)行計(jì)劃。

第三層則是存儲(chǔ)引擎了，Mysql通過執(zhí)行引擎直接調(diào)用存儲(chǔ)引擎API查詢數(shù)據(jù)庫中數(shù)據(jù)。

通過Mysql的架構(gòu)分層，我們首先就可以很清晰的了解到一個(gè)SQL的大概的執(zhí)行過程。

1. 首先客戶端發(fā)送請(qǐng)求到服務(wù)端，建立連接。
2. 服務(wù)端先看下查詢緩存是否命中，命中就直接返回，否則繼續(xù)往下執(zhí)行。
3. 接著來到解析器，進(jìn)行語法分析，一些系統(tǒng)關(guān)鍵字校驗(yàn)，校驗(yàn)語法是否合規(guī)。
4. 然后優(yōu)化器進(jìn)行SQL優(yōu)化，比如怎么選擇索引之類，然后生成執(zhí)行計(jì)劃。
5. 最后執(zhí)行引擎調(diào)用存儲(chǔ)引擎API查詢數(shù)據(jù)，返回結(jié)果。

這就是一個(gè)很概括性的SQL執(zhí)行過程，接下來，具體到每個(gè)步驟詳細(xì)說明一下。

查詢緩存

如果你翻看Mysql的官方文檔就會(huì)知道，查詢緩存在5.7.20版本已經(jīng)被棄用，并且8.0的版本已經(jīng)刪除了。為啥要?jiǎng)h除，可能覺得太雞肋了吧。

我們可以通過命令來查看查詢緩存是否可用。

mysql> SHOW VARIABLES LIKE 'have_query_cache'; 
+------------------+-------+ 
| Variable_name    | Value | 
+------------------+-------+ 
| have_query_cache | YES   | 
+------------------+-------+ 

除此之外，查詢緩存還有一些核心參數(shù)。更具體的說明可以參考官方文檔。

query_cache_type：是否打開查詢緩存，值為0\1\2，分別對(duì)應(yīng)為OFF\ON\DEMAND，ON的話則代表開啟查詢緩存，但是可以通過SELECT SQL_NO_CACHE來手動(dòng)禁用，DEMAND則代表只緩存以SELECT SQL_CACHE開頭的SQL語句。

query_cache_limit：緩存結(jié)果大小限制，如果查詢結(jié)果超過大小則不會(huì)被緩存，默認(rèn)是1M大小。

query_cache_size：為查詢緩存分配的內(nèi)存大小，他是1024的整數(shù)倍。

query_cache_min_res_unit：查詢緩存分配內(nèi)存塊的最小單位，默認(rèn)為4KB。這是查詢緩存分配內(nèi)存的基本單位，即便比如查詢的數(shù)據(jù)只有1個(gè)字節(jié)，也會(huì)按照最小內(nèi)存單元大小來分配內(nèi)存空間。

在進(jìn)行SQL解析之前，系統(tǒng)會(huì)判斷查詢緩存是否打開，如果打開，就拿緩存中的查詢和傳入的查詢比較，如果完全一樣，就會(huì)從緩存中直接返回。

但是需要特別注意的是，無論大小寫、空格還是注釋，都會(huì)影響緩存的命中結(jié)果，也就是說必須完全一樣!

比如以下的SQL大小寫不同、多了空格都無法命中查詢緩存。

select * from user; 
SELECT * from user; 
select   * from user; 

解析器&預(yù)處理器

如果查詢緩存未命中，就會(huì)進(jìn)入正常的SQL執(zhí)行環(huán)節(jié)。

首先就像我們正常的業(yè)務(wù)開發(fā)一樣，第一步都是對(duì)參數(shù)的規(guī)則校驗(yàn)，Mysql也一樣，解析器會(huì)進(jìn)行詞法語法分析，基于語法規(guī)則對(duì)SQL進(jìn)行校驗(yàn)。

比如關(guān)鍵字是否使用正確啊，或者說關(guān)鍵字順序是不是正確，比如說你把select寫成了selct，order by寫成了by order。

如果校驗(yàn)OK，那么就生成一顆“解析樹”。

接著預(yù)處理器就是進(jìn)一步依據(jù)合法規(guī)則生成的解析樹進(jìn)行校驗(yàn)，比如表名、列名是否存在等等。

優(yōu)化器

如果說解析器和預(yù)處理器是我們業(yè)務(wù)邏輯的前置校驗(yàn)環(huán)節(jié)，優(yōu)化器就是真正的處理業(yè)務(wù)邏輯的地方。

一條查詢SQL可以有N種執(zhí)行方式，優(yōu)化器的最終目標(biāo)是找到最好的執(zhí)行計(jì)劃，交給執(zhí)行引擎去執(zhí)行。

但是實(shí)際使用中我們經(jīng)常會(huì)發(fā)現(xiàn)，Mysql經(jīng)常有選擇錯(cuò)索引的情況，我明明有更快的索引，結(jié)果它不用，導(dǎo)致搞出了慢查詢。

這是因?yàn)镸ysql的優(yōu)化器是基于成本模型的優(yōu)化器，他只是基于已有的成本計(jì)算公式來選擇一個(gè)成本最低的執(zhí)行方式，這個(gè)執(zhí)行方式不一定會(huì)是最快的，只能說大多數(shù)時(shí)候，優(yōu)化器的選擇比我們自己的選擇更準(zhǔn)確。

總的來說，這個(gè)優(yōu)化過程太復(fù)雜了，流程大致就是下圖所示，更詳細(xì)的內(nèi)容可以看《數(shù)據(jù)庫查詢優(yōu)化器的藝術(shù)原理解析與SQL性能》這本書(我實(shí)在是懶得看了，吐了)。

執(zhí)行引擎

大部分核心的事情已經(jīng)被優(yōu)化器處理完了，最后執(zhí)行引擎只要根據(jù)生成好的執(zhí)行計(jì)劃查詢數(shù)據(jù)返回就好了，這一步相對(duì)就挺簡單了。

執(zhí)行引擎只需要根據(jù)執(zhí)行計(jì)劃的指令調(diào)用存儲(chǔ)引擎的API就可以了。

當(dāng)然這一步如果可以緩存查詢結(jié)果，那么就在這個(gè)階段把查詢結(jié)果緩存下來，然后把結(jié)果返回給客戶端就可以了。

總結(jié)

一圖勝千言。

本文轉(zhuǎn)載自微信公眾號(hào)「艾小仙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系艾小仙公眾號(hào)。