第一節(jié)、邏輯架構(gòu)剖析

1.1、服務(wù)器處理客戶端請求

不論客戶端進(jìn)程和服務(wù)器進(jìn)程是采用哪種方式進(jìn)行通信，最后實現(xiàn)的效果都是:客戶端進(jìn)程向服務(wù)器進(jìn)程發(fā)送一段文本(SQL語句)，服務(wù)器進(jìn)程處理后再向客戶端進(jìn)程發(fā)送一段文本(處理結(jié)果)。

上圖的處理流程在MySQL5.7和8.0中有所不同，只是一個通用的處理流程，后續(xù)會有更詳細(xì)的講解。

1.2、Connectors

Connectors，指的是不同語言中與SQL的交互。MySQL首先是一個網(wǎng)絡(luò)程序，在TCP之上定義了自己的應(yīng)用層協(xié)議。所以要使用MySQL，我們可以編寫代碼，跟MySQL Server建立TCP連接，之后按照其定義好的協(xié)議進(jìn)行交互。或者比較方便的辦法是調(diào)用SDK，比如Native C API、JDBC、PHP等各語言MysQL Connector，或者通過ODBC。但通過SDK來訪問MysQL，本質(zhì)上還是在TCP連接上通過MySQL協(xié)議跟MySQL進(jìn)行交互。

1.3、第1層：連接層

系統(tǒng)（客戶端）訪問MySQL 服務(wù)器前，做的第一件事就是建立TCP連接。
經(jīng)過三次握手建立連接成功后，MySQL服務(wù)器對TCP傳輸過來的賬號密碼做身份認(rèn)證、權(quán)限獲取。

1.4、第2層：服務(wù)層

第二層架構(gòu)主要完成大多數(shù)的核心服務(wù)功能，如SQL接口，并完成緩存的查詢，SQL的分析和優(yōu)化及部分內(nèi)置函數(shù)的執(zhí)行。所有跨存儲引擎的功能也在這一層實現(xiàn)，如過程、函數(shù)等。
在該層，服務(wù)器會解析查詢并創(chuàng)建相應(yīng)的內(nèi)部解析樹，并對其完成相應(yīng)的優(yōu)化︰如確定查詢表的順序，是否利用索引等，最后生成相應(yīng)的執(zhí)行操作。
如果是SELECT語句，服務(wù)器還會查詢內(nèi)部的緩存。如果緩存空間足夠大，這樣在解決大量讀操作的環(huán)境中能夠很好的提升系統(tǒng)的性能。

• SQL Interface: SQL接口
  1.接收用戶的SQL命令，并且返回用戶需要查詢的結(jié)果。比如SELECT … FROM就是調(diào)用SQLInterface。
  2.MySQL支持DML（數(shù)據(jù)操作語言）、DDL（數(shù)據(jù)定義語言）、存儲過程、視圖、觸發(fā)器、自定義函數(shù)等多種SQL語言接口。

• Parser: 解析器
  1.在解析器中對 SQL 語句進(jìn)行語法分析、語義分析。將SQL語句分解成數(shù)據(jù)結(jié)構(gòu)，并將這個結(jié)構(gòu)傳遞到后續(xù)步驟，以后SQL語句的傳遞和處理就是基于這個結(jié)構(gòu)的。如果在分解構(gòu)成中遇到錯誤，那么就說明這個SQL語句是不合理的。
  2.在SQL命令傳遞到解析器的時候會被解析器驗證和解析，并為其創(chuàng)建 語法樹 ，并根據(jù)數(shù)據(jù)字典豐富查詢語法樹，會 驗證該客戶端是否具有執(zhí)行該查詢的權(quán)限 。創(chuàng)建好語法樹后，MySQL還會對SQl查詢進(jìn)行語法上的優(yōu)化，進(jìn)行查詢重寫。

• Optimizer: 查詢優(yōu)化器
  1.SQL語句在語法解析之后、查詢之前會使用查詢優(yōu)化器確定 SQL 語句的執(zhí)行路徑，生成一個執(zhí)行計劃 。
  2.這個執(zhí)行計劃表明應(yīng)該 使用哪些索引 進(jìn)行查詢（全表檢索還是使用索引檢索），表之間的連接順序如何，最后會按照執(zhí)行計劃中的步驟調(diào)用存儲引擎提供的方法來真正的執(zhí)行查詢，并將查詢結(jié)果返回給用戶。

• Caches & Buffers： 查詢緩存組件
  1.MySQL內(nèi)部維持著一些Cache和Buffer，比如Query Cache用來緩存一條SELECT語句的執(zhí)行結(jié)果，如果能夠在其中找到對應(yīng)的查詢結(jié)果，那么就不必再進(jìn)行查詢解析、優(yōu)化和執(zhí)行的整個過程了，直接將結(jié)果反饋給客戶端。
  2.從MySQL 5.7.20開始，不推薦使用查詢緩存，并在 MySQL 8.0中刪除 。

1.5、 第3層：引擎層

插件式存儲引擎層（ Storage Engines），真正的負(fù)責(zé)了MySQL中數(shù)據(jù)的存儲和提取，對物理服務(wù)器級別維護(hù)的底層數(shù)據(jù)執(zhí)行操作，服務(wù)器通過API與存儲引擎進(jìn)行通信。不同的存儲引擎具有的功能不同，這樣我們可以根據(jù)自己的實際需要進(jìn)行選取。

1.6、 存儲層

所有的數(shù)據(jù)，數(shù)據(jù)庫、表的定義，表的每一行的內(nèi)容，索引，都是存在 文件系統(tǒng) 上，以 文件 的方式存在的，并完成與存儲引擎的交互。當(dāng)然有些存儲引擎比如InnoDB，也支持不使用文件系統(tǒng)直接管理裸設(shè)備，但現(xiàn)代文件系統(tǒng)的實現(xiàn)使得這樣做沒有必要了。在文件系統(tǒng)之下，可以使用本地磁盤，可以使用DAS、NAS、SAN等各種存儲系統(tǒng)。

1.7、小結(jié)

1. 連接層：客戶端和服務(wù)器端建立連接，客戶端發(fā)送 SQL 至服務(wù)器端；
2. SQL 層（服務(wù)層）：對 SQL 語句進(jìn)行查詢處理；與數(shù)據(jù)庫文件的存儲方式無關(guān)；
3. 存儲引擎層：與數(shù)據(jù)庫文件打交道，負(fù)責(zé)數(shù)據(jù)的存儲和讀取。

第二節(jié)、SQL執(zhí)行流程

2.1、查詢緩存

如果在查詢緩存中發(fā)現(xiàn)了這條 SQL 語句，就會直接將結(jié)果返回給客戶端；如果沒有，就進(jìn)入到解析器階段。需要說明的是，因為查詢緩存往往效率不高，所以在 MySQL8.0 之后就拋棄了這個功能。

查詢緩存是提前把查詢結(jié)果緩存起來，這樣下次不需要執(zhí)行就可以直接拿到結(jié)果。需要說明的是，在MySQL 中的查詢緩存，不是緩存查詢計劃，而是查詢對應(yīng)的結(jié)果。這就意味著查詢匹配的 魯棒性大大降低 ，只有 相同的查詢操作才會命中查詢緩存 。兩個查詢請求在任何字符上的不同（例如：空格、注釋、大小寫），都會導(dǎo)致緩存不會命中。因此 MySQL 的 查詢緩存命中率不高 。

2.2、解析器

在解析器中對 SQL 語句進(jìn)行語法分析、語義分析。說白了就是看SQL語句的寫法對不對，如果語法沒問題，再看SQL語句的各個部分是做什么的。

2.3、優(yōu)化器

在優(yōu)化器中會確定 SQL 語句的執(zhí)行路徑，比如是根據(jù) 全表檢索 ，還是根據(jù) 索引檢索 等。經(jīng)過上一步的解析器，MySQL就知道你要做什么了。在開始執(zhí)行之前，還要先經(jīng)過優(yōu)化器的處理。一條查詢可以有很多種執(zhí)行方式，最后都返回相同的結(jié)果。優(yōu)化器的作用就是找到這其中最好的執(zhí)行計劃。

比如:優(yōu)化器是在表里面有多個索引的時候，決定使用哪個索引;或者在一個語句有多表關(guān)聯(lián)（join)的時候,決定各個表的連接順序，還有表達(dá)式簡化、子查詢轉(zhuǎn)為連接、外連接轉(zhuǎn)為內(nèi)連接等。

2.4、執(zhí)行器

SQL的執(zhí)行流程在5.7和8.0中有所不同，后續(xù)如果有需要再進(jìn)行詳細(xì)學(xué)習(xí)。

第三節(jié)、數(shù)據(jù)庫緩沖池(buffer pool)