文章已托管到GitHub，大家可以去GitHub查看閱讀，歡迎老闆們前來Star！ 搜索關註微信公眾號 碼出Offer 領取各種學習資料！

MySQL基礎架構

一、引言

我們在學習MySQL的時候，邁入MySQL大門的第一步就是瞭解並安裝MySQL客戶端，隨後才是使用MySQL做一系列資料庫操作。但是往往被我們忽略的卻是真正瞭解MySQL基礎架構，為什麼要這麼說呢？因為在對資料庫數據CURD操作的時候，也會出現一些問題或異常情況，此時並不是要去盲目的解決問題，而是直戳本質，快速定位並解決問題。

二、MySQL基礎架構圖

MySQL基礎架構可以分為兩大類：Server層和存儲引擎層

• Server層： Server層涵蓋了MySQL大部分核心業務功能，並且所有存儲引擎的功能都在這一層實現
• 存儲引擎層： 存儲引擎有很多，各自有著各自的特點，可以根據場景來選擇不同的存儲引擎來操作數據

Server層	存儲引擎層

三、MySQL基礎架構零件分析

• 連接器： 管理連接，許可權驗證
• 分析器： 詞法分析，語法分析
• 查詢緩存： 命中緩存，返回結果
• 優化器： 執行計劃生成，索引選擇
• 執行器： 操作引擎，返回結果
• 存儲引擎： 存儲數據，提供讀寫介面

四、基礎零件剖析

4.1 連接器

使用MySQL資料庫，第一步是要連接MySQL資料庫，這時候第一個迎接的你就是連接器。連接器負責跟客戶端建立連接、獲取許可權、管理連接等工作。我們一般是使用命令mysql -uroot -p + Enter後輸入密碼並登錄。當輸入密碼提交登錄時，MySQL客戶端會與伺服器建立連接，在完成TCP握手後，連接器就開始確認你所輸入的用戶名和密碼。如果用戶名密碼正確則成功登錄，如果用戶名密碼錯誤，會受到如下錯誤信息！

登錄失敗錯誤信息

登陸成功後，連接器會對你進行許可權驗證，此時許可權驗證都依賴於這時候讀取到的許可權，並根據你的許可權而賦予對資料庫的操作的權力。正是因為許可權驗證對驗證時許可權讀取的依賴問題，也反映出瞭如下註意點！

註意： 一個用戶成功建立連接後，即使你用管理員賬號對這個用戶的許可權做了修改，也不會影響已經存在連接的許可權。修改完成後，只有再新建的連接才會使用新的許可權設置。

4.2 查詢緩存

連接建立完成後，假設你正在使用該SQL語句查詢一條數據select * from tb_user where id = 1。接下來MySQL執行邏輯就回到了查詢緩存中。此時MySQL拿到一個查詢請求後，先到查詢緩存里看看是否執行過一這條SQL語句，在之前如果執行過這條語句，其結果大概就是以Key-Value（鍵值對）的形式直接緩存在記憶體中。這裡的Key代指的是查詢語句，Value代指的是查詢結果。如果你所查詢的語句在查詢緩存中就命中緩存，它就會把該SQL語句對應的value值結果集返回，這樣就並不會執行其他MySQL零部件了，大大提高了查詢效率。

但是往往利弊是同時存在的，查詢緩存有著一個致命的缺點，那就是查詢緩存失效十分頻繁。這裡所說的查詢緩存失效是指的只要有對一個表的更新，這個表上所有的查詢緩存都會被清空。因此可能你廢了很大的勁把結果存起來，還沒使用呢，就被一個更新全清空了！大家都知道數據的寶貴，由於這個致命的缺點，導致查詢緩存在MySQL8.0版本的時候就被拋棄了，也就是說MySQL8.0版本徹底刪除了查詢緩存！

4.3 分析器

如果沒有命中緩存，那就必須執行SQL語句了。這時候你所寫的查詢語句就到了分析器，分析器先會對SQL語句進行“詞法分析”，它會分析並識別你所輸入的空格、字元串和關鍵字都在MySQL中代表了什麼，比如首先它會識別出來select關鍵字、表名、列名和條件。識別了SQL語句的這些後，就到了“語法分析”的階段，它會根據MySQL的語句標準來檢查你所輸入的SQL語句是否符合標準。如果不符合標準就會報出一個“You have an error in your SQL syntax”的語法錯誤提示。

註意： 一般語法錯誤提示第一個你所需要關註的是緊接著“use near”的內容，因為它會告訴你哪個語法附近有錯誤！

4.4 優化器

能進到優化器優化環節的SQL語句，說明在分析器分析的時候沒有出現任何錯誤。那麼優化器對該SQL語句做了些什麼呢？假如一個SQL語句中是有索引的，優化器會根據優化規則選擇合適的索引。或者是一個語句奪標關聯時，優化器決定了各個表之間的連接順序。這裡我們看一個多表連接的SQL語句：

select * from tb_user join tb_grade on tb_user.id = tb_grade.uid where tb_user.username = 'Ziph' and tb_grade.subject = 'Java';

• 先從tb_user表中取出username=Ziph的記錄ID，再根據ID關聯到tb_grade表，再判斷tb_grade表中的subject是否等於Java

• 先從tb_grade表中取出subject=Java的記錄ID，再根據ID關聯到tb_user表，再判斷tb_user表中的username是否等於Ziph

兩種邏輯查詢出的結果雖然是一樣的，但是執行效率會有所不同，而優化器的作用就是根據自己的優化邏輯判斷來決定使用哪一個方案

4.5 執行器

通過分析器知道了做什麼，通過優化器知道了怎麼做，這就遇到了一個問題，誰來做？可想而知就是執行器開始執行SQL語句。開始執行的時候，要先判斷一下你對錶是否有執行查詢的許可權，如果沒有就會報出錯誤的提示信息。如果有許可權，就打開表繼續執行。執行器會根據表的引擎來調用提供的引擎介面，開始執行。

執行器調用引擎介面執行過程： 調用InnoDB引擎介面取這個表的第一行，判斷是否符合查詢條件，如果不符合則跳過，如果符合則將這行存在結果集中。以此類推，執行遍歷所有行將所有滿足條件的記錄集作為結果集返回