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

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

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

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

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

首先客戶端發(fā)送請求到服務(wù)端，建立連接。

服務(wù)端先看下查詢緩存是否命中，命中就直接返回，否則繼續(xù)往下執(zhí)行。

接著來到解析器，進行語法分析，一些系統(tǒng)關(guān)鍵字校驗，校驗語法是否合規(guī)。

然后優(yōu)化器進行SQL優(yōu)化，比如怎么選擇索引之類，然后生成執(zhí)行計劃。

最后執(zhí)行引擎調(diào)用存儲引擎API查詢數(shù)據(jù)，返回結(jié)果。

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

查詢緩存

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果校驗OK，那么就生成一顆“解析樹”。

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

優(yōu)化器

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

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

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

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

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

執(zhí)行引擎

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

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

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

總結(jié)

一圖勝千言。

總結(jié)

以上是生活随笔為你收集整理的面试官：说说一条查询SQL的执行过程？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。