[[420209]]

select * from XXX where id=1;

這應(yīng)該是n年前入門mysql必用的查詢語句了吧，學(xué)如逆水行舟，不進(jìn)則退，這么久過去了，你知道這條語句在Mysql內(nèi)部的執(zhí)行過程嗎?

我們先來看看司空見慣的Mysql基本架構(gòu)示意圖

可以看到，Mysql可以分為

• Server層，包括連接器、查詢緩存、分析器、優(yōu)化器、執(zhí)行器等，除了直接落地到磁盤、和從磁盤提取數(shù)據(jù)外的所有能力。
• 存儲引擎層，負(fù)責(zé)了數(shù)據(jù)的讀取和存儲，支持InnoDB、MyISAM、Memory等多個存儲引擎，默認(rèn)的是InnoBD。

結(jié)構(gòu)大概講完了，有沒有感覺，Mysql就像一個大型的加工廠，你把原材料，也就是sql語句放進(jìn)去，然后Mysql就轉(zhuǎn)動起來，從頭到尾給你加工，最后得出一款產(chǎn)品，也就是執(zhí)行結(jié)果。

嗯，這個比喻好，確實他媽的像，那么這個加工廠具體做了啥呢?

連接器小妹妹

首先，我們都會使用連接命令連上mysql

mysql -hip-pport -u$user -p

這個時候，出來接待我們的就是連接器小妹妹了

連接器小妹妹負(fù)責(zé)跟我們進(jìn)行了典型的TPC握手，然后開始問我們的身份，要拿芝麻開門什么的密碼來驗證我們是否有權(quán)限，如果賬戶或者密碼錯誤了，則會直接跟我們說

"Access denied for user“

驗證通過了，則我們和連接器的連接便成功簡歷了，可以使用

show processlist

查看連接的狀態(tài)

其中Sleep狀態(tài)表明是空閑連接

連接建立后，連接器小妹妹還會告訴我們一些規(guī)則，比如

如果連接太長時間沒動靜，則會自動將連接斷開，默認(rèn)是8個小時

如果連接被斷開了，等我嗎再次發(fā)送請求的時候，連接器小妹妹則會告訴我們

Lost connection to MySQL server during query

那么能改嗎?

可以的，只需要我們告訴連接器小妹妹，將wait_timeout的參數(shù)修改一下就可以了

聽起來都是長連接，那么能進(jìn)行短連接嗎?

可以的，連接器小妹妹說了：

如果你們和我建立長連接的話，連接成功后，你們后續(xù)有請求，都會一直使用同一個連接。但是如果是短連接，則每次執(zhí)行完很少的幾次操作后我就要就斷開連接了，下次再來你們再建立一次連接吧

我們也可以看到，其實和連接器小妹妹建立連接的過程是挺麻煩的，所以平常我們盡量會減少這個行為，一般都會使用長連接。

但是啊，有時候用著用著，mysql這邊內(nèi)存漲的特別快，這是為什么呢?我特地問了連接器小妹妹，她告訴我

mysql在執(zhí)行過程中臨時使用的內(nèi)存是管理在連接對象里邊的，而這些對象只有在連接斷開的時候才釋放，所以內(nèi)存占用越來越大，最后有可能被系統(tǒng)強行干掉了，也就是OOM

丟，這么嚴(yán)重，那么我到底用長連接還是短連接呢?

肯定是長連接啦，別急，還是有解決辦法的，我們這邊給了兩個方案

• 定期斷開長連接，使用一段時間，或者程序里面判斷執(zhí)行過一個占用內(nèi)存的大查詢后，斷開 連接，之后要查詢再重連。
• 如果你用的是MySQL 5.7或更新版本，可以在每次執(zhí)行一個比較大的操作后，通過執(zhí)行mysql_reset_connection來重新初始化連接資源。這個過程不需要重連和重新做權(quán)限驗證， 但是會將連接恢復(fù)到剛剛創(chuàng)建完時的狀態(tài)。

到了這里，連接器小妹妹的活就干完了，后面出來接待我們的是緩存查詢小哥哥。

緩存查詢小哥哥

緩存查詢小哥哥也比較簡單，一來就將我們的sql語句拿去做對比，他那邊有個字典，用key-value的格式記錄著查詢過的key和結(jié)果，而他的做法也極其簡單，只要找到一樣的，則將結(jié)果給回我們了，只有當(dāng)找不到記錄，才會繼續(xù)走后面的流程，然后繼續(xù)記錄到字典內(nèi)。

這個時候，我就很疑惑了，如果實際上數(shù)據(jù)更新了，但是你的字典還是舊的怎么辦呢?

緩存查詢小哥哥說了，這個不用擔(dān)心，字典上會記錄著查詢記錄對應(yīng)的表，如果對應(yīng)的表有了更新，我這邊就會將記錄全部清空掉的。

哦，這樣子，那么如果是更新比較頻繁的情況，可能你的作用也不大哦哈哈哈

是的，你們可以通過

query_cache_type = DEMAND

將關(guān)閉掉的，而且在8.0開始，我已經(jīng)被移除啦。

說完緩存查詢小哥哥流下了悲傷的淚水，是啊，畢竟跟不上時代的技術(shù)，被淘汰也是難免的。

緩存查詢小哥哥說完，便將另一位小哥叫了出來，這位小哥叫分析器。

分析器小哥哥

分析器小哥哥在拿到sql語句后，就開始自己搗鼓了起來，那么他具體做了啥呢?我們在旁邊看搗鼓了很久，其實他就做了兩步

第一步，詞法分析，就是從SQL 語句中提取關(guān)鍵字，比如：查詢的表，字段名，查詢條件等等。

第二步，語法規(guī)則，就是判斷SQL語句是否合乎MySQL的語法。

通過分析器小哥哥做的事情，我也明白了，其實詞法分析就是將整個SQL語句拆分成一個個單詞，而語法規(guī)則則根據(jù)MySQL定義的語法規(guī)則生成對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，并存儲在對象結(jié)構(gòu)當(dāng)中。

舉個例子，假設(shè)有這樣一個SQL語句“select id from XXX”。

先通過詞法分析，從左到右逐個字符進(jìn)行解析

然后再通過語法規(guī)則解析，判斷輸入的SQL 語句是否滿足MySQL語法，并且生成語法樹，語法樹大概是這樣的

優(yōu)化器小姐姐

到了這里，優(yōu)化器小姐姐已經(jīng)知道我們要干嘛了 畢竟分析器小哥哥已經(jīng)幫他分析好了，只是可能我們的語句不夠優(yōu)美，所以才需要知心的優(yōu)化器小姐姐來做優(yōu)化。

知心小姐姐怎么做的呢?我們看到小姐姐先將SQL語法樹拿了出來，然后就開始工作了起來，不得不說，小姐姐工作的樣子是真的好看，那么她具體做了啥呢?

在全程圍觀的我們，看到了她大概做了兩件事

• 邏輯變化
• 代價優(yōu)化

邏輯變化是啥呢?邏輯變換就是在關(guān)系代數(shù)基礎(chǔ)上進(jìn)行變換，其目的是為了化簡，同時保證SQL變化前后的結(jié)果一致，也就是邏輯變化并不會帶來結(jié)果集的變化。

其主要包括以下幾個方面：

• 否定消除：針對表達(dá)式“和取”或“析取”前面出現(xiàn)“否定”的情況，應(yīng)將關(guān)系條件進(jìn)行拆分，從而將外層的“NOT”消除。
• 等值常量傳遞：利用了等值關(guān)系的傳遞特性，為了能夠盡早執(zhí)行“下推”運算。“下推”的基本策略是，始終將過濾表達(dá)式盡可能移至靠近數(shù)據(jù)源的位置。
• 常量表達(dá)式計算：對于能立刻計算出結(jié)果的表達(dá)式，直接計算結(jié)果，同時將結(jié)果與其他條件盡量提前進(jìn)行化簡。

總結(jié)下來就是替換和預(yù)處理啦。

代價優(yōu)化呢?代價優(yōu)化是用來確定每個表，根據(jù)條件是否應(yīng)用索引，應(yīng)用哪個索引和確定多表連接的順序等問題，為了完成代價優(yōu)化，需要找到一個代價最小的方案。

可以這說，我們要執(zhí)行的查詢都是通過代價優(yōu)化來計算出來的，最終得出了最小代價計劃去執(zhí)行。

優(yōu)化好后，接下來就是我們的執(zhí)行器大哥出馬了。

執(zhí)行器大哥

到了這一步，就要準(zhǔn)備執(zhí)行了，開始執(zhí)行的時候，執(zhí)行器大哥會一臉嚴(yán)肅的翻看他的權(quán)限寶典

查看我們是否有執(zhí)行查詢的權(quán)限，如果沒有，則會直接告訴我們

SELECT command denied to user 'root'@'localhost' for table 'XXX'

如果驗證沒問題，他則會根據(jù)表的引擎信息，判斷要調(diào)用哪種引擎接口

例如SQL：select * from XXX where id=1;

假設(shè) “id“ 字段沒有設(shè)置索引，就會調(diào)用存儲引擎從第一條開始查，如果碰到了id是1， 就將結(jié)果集返回，沒有查找到就查看下一行，重復(fù)上一步的操作，直到讀完整個表或者找到對應(yīng)的記錄。

執(zhí)行器還畫了個草圖解釋了他一貫的執(zhí)行順序

最后

一條查詢命令到了這里就算結(jié)束了，大致介紹了查詢請求的執(zhí)行流程，引入了連接器、查詢緩存、分析器、優(yōu)化器、執(zhí)行器幾兄弟的分工合作，最后，我們?yōu)榧磳⑾У牟樵兙彺嫫鞯艿苣昼?.....

本文轉(zhuǎn)載自微信公眾號「稀飯下雪」