MySQL基礎架構分析

文章已託管到GitHub，你們能夠去GitHub查看閱讀，歡迎老闆們前來Star！ 搜索關注微信公衆號 碼出Offer 領取各類學習資料！

MySQL基礎架構

---

1、引言

咱們在學習MySQL的時候，邁入MySQL大門的第一步就是了解並安裝MySQL客戶端，隨後纔是使用MySQL作一系列數據庫操做。可是每每被咱們忽略的倒是真正瞭解MySQL基礎架構，爲何要這麼說呢？由於在對數據庫數據CURD操做的時候，也會出現一些問題或異常狀況，此時並非要去盲目的解決問題，而是直戳本質，快速定位並解決問題。

2、MySQL基礎架構圖

MySQL基礎架構能夠分爲兩大類：Server層和存儲引擎層

• Server層： Server層涵蓋了MySQL大部分核心業務功能，而且全部存儲引擎的功能都在這一層實現
• 存儲引擎層： 存儲引擎有不少，各自有着各自的特色，能夠根據場景來選擇不一樣的存儲引擎來操做數據

Server層	存儲引擎層
Server層	存儲引擎層

3、MySQL基礎架構零件分析

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

4、基礎零件剖析

4.1 鏈接器

使用MySQL數據庫，第一步是要鏈接MySQL數據庫，這時候第一個迎接的你就是鏈接器。鏈接器負責跟客戶端創建鏈接、獲取權限、管理鏈接等工做。咱們通常是使用命令mysql -uroot -p + Enter後輸入密碼並登陸。當輸入密碼提交登陸時，MySQL客戶端會與服務器創建鏈接，在完成TCP握手後，鏈接器就開始確認你所輸入的用戶名和密碼。若是用戶名密碼正確則成功登陸，若是用戶名密碼錯誤，會受到以下錯誤信息！

登陸失敗錯誤信息
image-20200712114731957

登錄成功後，鏈接器會對你進行權限驗證，此時權限驗證都依賴於這時候讀取到的權限，並根據你的權限而賦予對數據庫的操做的權力。正是由於權限驗證對驗證時權限讀取的依賴問題，也反映出了以下注意點！

注意： 一個用戶成功創建鏈接後，即便你用管理員帳號對這個用戶的權限作了修改，也不會影響已經存在鏈接的權限。修改完成後，只有再新建的鏈接纔會使用新的權限設置。

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引擎接口取這個表的第一行，判斷是否符合查詢條件，若是不符合則跳過，若是符合則將這行存在結果集中。以此類推，執行遍歷全部行將全部知足條件的記錄集做爲結果集返回

在這裏插入圖片描述