一篇學會 MySQL 體系架構
2022-10-2735
前面三篇文章我們一起分析了外部環境對 MySQL 性能的影響，不過起決定作用的還是 MySQL 自身，今天我們就來看看 MySQL 體系架構，看看這個數據庫到底是怎么組成的。
MySQL 是一個典型的 C/S 架構應用程序，MySQL 提供數據庫服務，完成客戶端的請求和操作， 則負責連接到 。很多初學者并不太容易區分出 MySQL 和 ，因為當我們安裝完 MySQL 之后，默認情況下 和 就都具備了，我們在命令行連接并登錄 MySQL 服務，這個其實就是由 提供的服務。MySQL 和其他關系型數據庫不一樣的地方在于它的彈性以及可以通過插件形式提供不同種類的存儲引擎，MySQL 請求處理過程會根據不同的存儲引擎發生變化，這是它的特色。
1、MySQL 存儲引擎
這里我主要和大家介紹下 MySQL 存儲引擎的歷史，至于每一個存儲引擎的特點，松哥將在后面的文章中和大家詳細介紹。
MySQL 從設計之初，存儲引擎就是可插拔的，允許公司或者個人按照自己的需求定義自己的存儲引擎(當然，普通的公司或者個人其實是沒有這個實力的)。MySQL 自研的使用較廣的存儲引擎是 ， 支持表鎖，不支持行鎖，所以在處理高并發寫操作時效率要低一些，另外 也不支持外鍵(雖然現在實際項目中外鍵已經用的比較少了)。
雖然 看起來有些簡陋，但這并不影響 MySQL 的流行，這就不得不說 MySQL 中另外一個大名鼎鼎的存儲引擎 了。
存儲引擎是由一家位于芬蘭赫爾辛基的名為 Oy 的公司開發的， 存儲引擎的歷史甚至比 MySQL 還要悠久。可能會有小伙伴決定奇怪，插件竟然比起宿主還要歷史悠久?
剛剛開發的時侯，就是作為一個完整的數據庫來開發的，因此功能很完備。開發出來之后，創始人是想將這個數據庫賣掉的，但是沒有找到買家。
后來 .0 推出后，這種可插拔的存儲引擎吸引了 Oy 公司創始人 Tuuri 的注意，在和 MySQL 溝通之后，決定將 作為一個存儲引擎引入到 MySQL 中(這就是為什么 比 MySQL 還歷史悠久的原因)，MySQL 雖然支持 ，但是實際上還是主推自家的 。
但是 實在太優秀了，最終在 2006 年的時侯，成功吸引到大魔王 的注意，大手一揮，就把 收購了。
MySQL 主推自家的 ，日子過得也很慘淡，最終在 2008 年被 sun 公司以 10 億美元拿下，這個操作鞏固了 sun 在開源領域的領袖地位，可是一直以來 sun 公司的變現能力都比較弱，最終 sun 自己在 2009 年被 收入囊中。
收購 sun 之后， 和 MySQL 就都成了 的產品了，這下整合就變得非常容易了，在后來發布的版本中， 慢慢就成為了 MySQL 的默認存儲引擎。在最新的 中，元數據表也使用了 作為存儲引擎。
存儲引擎主要有如下特點：
支持事務支持 4 個級別的事務隔離支持多版本讀支持行級鎖讀寫阻塞與事務隔離級別相關支持緩存，既能緩存索引，也能緩存數據整個表和主鍵以 方式存儲，組成一顆平衡樹
當然也不是說 一定就是好的，在實際開發中，還是要根據具體的場景來選擇到底是使用 還是 。
(該引擎在 5.5 前的 MySQL 數據庫中為默認存儲引擎)特點：
沒有提供對數據庫事務的支持不支持行級鎖和外鍵由于 2，導致當執行 插入或 更新語句時，即執行寫操作需要鎖定整個表，所以會導致效率降低 保存了表的行數，當執行 COUNT(*) FROM TABLE 時，可以直接讀取相關值，不用全表掃描，速度快。
兩者區別：
是非事務安全的，而 是事務安全的 鎖的粒度是表級的網維大師8系列數據庫訪問工具 教程，而 支持行級鎖 支持全文類型索引，而 在 .6 之前不支持全文索引，從 .6 之后開始支持 索引了()。
使用場景比較：
如果要執行大量 操作，應該選擇 如果要執行大量 和 操作，應該選擇 大尺寸的數據集趨向于選擇 引擎，因為它支持事務處理和故障恢復。數據庫的大小決定了故障恢復的時間長短， 可以利用事務日志進行數據恢復，這會比較快。主鍵查詢在 引擎下也會相當快，不過需要注意的是如果主鍵太長也會導致性能問題。
相對來說， 在互聯網公司使用更多一些。
這是我們對 MySQL 存儲引擎的一個簡略介紹，后面松哥會專門寫文章來詳細介紹每一種存儲引擎的特點，歡迎大家一起來討論。
2、MySQL 架構
接下來我們再來看看 MySQL 的軟件架構(圖片源自網絡)。
從上圖我們可以大概看出來，MySQL 架構大致上可以分為三層：
客戶端(應用層)服務層存儲引擎層
我們分別來看。
2.1 客戶端
基本上所有的 C/S 架構的程序都有一個客戶端層，這一層主要包含如下三方面的內容：
2.2 服務層
MySQL 服務層的東西主要有六方面，我們來逐個分析。
2.2.1 系統管理和控制工具
2.2.2 連接池
這個前面已經提到過，連接池負責存儲和管理客戶端與數據庫的連接，一個線程管理一個連接。
2.2.3 SQL 接口
SQL 接口用來接受客戶端發送來的各種 SQL 命令，并且返回用戶需要的查詢結果。
如：
等都在這里被處理。
2.2.4 解析器
解析器的作用主要是解析查詢語句，將客戶端請求的 SQL 解析生成一個“解析樹”，然后根據 MySQL 的語法規則檢查解析樹是否合法，如果語句語法有錯誤，則返回相應的錯誤信息。
語法檢查通過后，解析器會查詢緩存，如果緩存中有對應的語句，就直接返回結果不進行接下來的優化執行操作。
2.2.5 查詢優化器
看名字就知道，這一步主要在解析器完成解析并對 SQL 語法進行檢查之后，對查詢語句進行優化，主要的優化方式包括選擇合適的索引以及數據讀取方式。
2.2.6 緩存
包括全局和引擎特定的緩存，提高查詢的效率。如果查詢緩存中有命中的查詢結果，則查詢語句就可以從緩存中取數據，無須再通過解析和執行。這個緩存機制是由一系列小緩存組成，如表緩存、記錄緩存、key 緩存、權限緩存等。
2.3 存儲引擎層
存儲引擎負責 MySQL 中數據的存儲與提取，與底層系統文件進行交互。
MySQL 存儲引擎是可插拔的，服務器中的查詢執行引擎通過接口與存儲引擎進行通信，接口屏蔽了不同存儲引擎之間的差異。現在有很多種存儲引擎，各有各的特點，最常見的是 和 。
需要注意的是，MySQL 存儲引擎是針對數據表而不是針對數據庫，換句話說，在同一個數據庫中網維大師8系列數據庫訪問工具 教程，我們可以同時使用多種不同的存儲引擎(技術上可以，實際不推薦)。
3、小結
MySQL 的這種分層設計為我們屏蔽了很多底層的東西，例如存儲引擎的具體工作機制很多時候對開發工程師而言就是透明的，我們不需要關系 怎么工作的，寫好自己的 SQL 就行(個別存儲引擎支持的 SQL 也有差異，這個另論)，這樣對開發工程師來說是更加友好了。
好啦，今天就和小伙伴們先扯這么多～
參考資料：