MySQL基礎架構分析
文章已託管到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引擎介面取這個表的第一行，判斷是否符合查詢條件，如果不符合則跳過，如果符合則將這行存在結果集中。以此類推，執行遍歷所有行將所有滿足條件的記錄集作為結果集返回
