[[409396]]

前面三篇文章我們一起分析了外部環境對 MySQL 性能的影響，不過起決定作用的還是 MySQL 自身，今天我們就來看看 MySQL 體系架構，看看這個數據庫到底是怎么組成的。

MySQL 是一個典型的 C/S 架構應用程序，MySQL Server 提供數據庫服務，完成客戶端的請求和操作，Client 則負責連接到 Server。很多初學者并不太容易區分出 MySQL Server 和 Client，因為當我們安裝完 MySQL 之后，默認情況下 Server 和 Client 就都具備了，我們在命令行連接并登錄 MySQL 服務，這個其實就是由 Client 提供的服務。MySQL 和其他關系型數據庫不一樣的地方在于它的彈性以及可以通過插件形式提供不同種類的存儲引擎，MySQL 請求處理過程會根據不同的存儲引擎發生變化，這是它的特色。

1、MySQL 存儲引擎

這里我主要和大家介紹下 MySQL 存儲引擎的歷史，至于每一個存儲引擎的特點，松哥將在后面的文章中和大家詳細介紹。

MySQL 從設計之初，存儲引擎就是可插拔的，允許公司或者個人按照自己的需求定義自己的存儲引擎(當然，普通的公司或者個人其實是沒有這個實力的)。MySQL 自研的使用較廣的存儲引擎是 MyISAM ，MyISAM 支持表鎖，不支持行鎖，所以在處理高并發寫操作時效率要低一些，另外 MyISAM 也不支持外鍵(雖然現在實際項目中外鍵已經用的比較少了)。

雖然 MyISAM 看起來有些簡陋，但這并不影響 MySQL 的流行，這就不得不說 MySQL 中另外一個大名鼎鼎的存儲引擎 InnoDB 了。

InnoDB 存儲引擎是由一家位于芬蘭赫爾辛基的名為 Innobase Oy 的公司開發的，InnoDB 存儲引擎的歷史甚至比 MySQL 還要悠久?？赡軙行』锇闆Q定奇怪，插件竟然比起宿主還要歷史悠久?

InnoDB 剛剛開發的時侯，就是作為一個完整的數據庫來開發的，因此功能很完備。開發出來之后，創始人是想將這個數據庫賣掉的，但是沒有找到買家。

后來 MySQL2.0 推出后，這種可插拔的存儲引擎吸引了 Innobase Oy 公司創始人 Heikki Tuuri 的注意，在和 MySQL 溝通之后，決定將 InnoDB 作為一個存儲引擎引入到 MySQL 中(這就是為什么 InnoDB 比 MySQL 還歷史悠久的原因)，MySQL 雖然支持 InnoDB ，但是實際上還是主推自家的 MyISAM。

但是 InnoDB 實在太優秀了，最終在 2006 年的時侯，成功吸引到大魔王 Oracle 的注意，大手一揮，就把 InnoDB 收購了。

MySQL 主推自家的 MyISAM ，日子過得也很慘淡，最終在 2008 年被 sun 公司以 10 億美元拿下，這個操作鞏固了 sun 在開源領域的領袖地位，可是一直以來 sun 公司的變現能力都比較弱，最終 sun 自己在 2009 年被 Oracle 收入囊中。

Oracle 收購 sun 之后，InnoDB 和 MySQL 就都成了 Oracle 的產品了，這下整合就變得非常容易了，在后來發布的版本中，InnoDB 慢慢就成為了 MySQL 的默認存儲引擎。在最新的 MySQL8 中，元數據表也使用了 InnoDB 作為存儲引擎。

InnoDB 存儲引擎主要有如下特點：

1. 支持事務
2. 支持 4 個級別的事務隔離
3. 支持多版本讀
4. 支持行級鎖
5. 讀寫阻塞與事務隔離級別相關
6. 支持緩存，既能緩存索引，也能緩存數據
7. 整個表和主鍵以 Cluster 方式存儲，組成一顆平衡樹

當然也不是說 InnoDB 一定就是好的，在實際開發中，還是要根據具體的場景來選擇到底是使用 InnoDB 還是 MyISAM 。

MyIASM(該引擎在 5.5 前的 MySQL 數據庫中為默認存儲引擎)特點：

1. MyISAM 沒有提供對數據庫事務的支持
2. 不支持行級鎖和外鍵
3. 由于 2，導致當執行 INSERT 插入或 UPDATE 更新語句時，即執行寫操作需要鎖定整個表，所以會導致效率降低
4. MyISAM 保存了表的行數，當執行 SELECT COUNT(*) FROM TABLE 時，可以直接讀取相關值，不用全表掃描，速度快。

兩者區別：

1. MyISAM 是非事務安全的，而 InnoDB 是事務安全的
2. MyISAM 鎖的粒度是表級的，而 InnoDB 支持行級鎖
3. MyISAM 支持全文類型索引，而 InnoDB 在 MySQL5.6 之前不支持全文索引，從 MySQL5.6 之后開始支持 FULLTEXT 索引了(https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html)。

使用場景比較：

1. 如果要執行大量 select 操作，應該選擇 MyISAM
2. 如果要執行大量 insert 和 update 操作，應該選擇 InnoDB
3. 大尺寸的數據集趨向于選擇 InnoDB 引擎，因為它支持事務處理和故障恢復。數據庫的大小決定了故障恢復的時間長短，InnoDB 可以利用事務日志進行數據恢復，這會比較快。主鍵查詢在 InnoDB 引擎下也會相當快，不過需要注意的是如果主鍵太長也會導致性能問題。

相對來說，InnoDB 在互聯網公司使用更多一些。

這是我們對 MySQL 存儲引擎的一個簡略介紹，后面松哥會專門寫文章來詳細介紹每一種存儲引擎的特點，歡迎大家一起來討論。

2、MySQL 架構

接下來我們再來看看 MySQL 的軟件架構(圖片源自網絡)。

從上圖我們可以大概看出來，MySQL 架構大致上可以分為三層：

1. 客戶端(應用層)
2. 服務層
3. 存儲引擎層

我們分別來看。

2.1 客戶端

基本上所有的 C/S 架構的程序都有一個客戶端層，這一層主要包含如下三方面的內容：

• 連接處理：當一個客戶端向服務端發送連接請求后，MySQL Server 會從線程池中分配一個線程來和客戶端進行連接，以后該客戶端的請求都會被分配到該線程上。MySQL Server 為了提高性能，提供了線程池，減少了創建線程和釋放線程所花費的時間。主流的程序設計語言都可以使用各自的 API 來與 MySQL 建立連接。
• 用戶認證：當客戶端向 MySQL 服務端發起連接請求后，MySQL Server 會對發起連接的用戶進行認證處理，MySQL 認證依據是: 用戶名，客戶端主機地址和用戶密碼。
• 用戶鑒權：當客戶連接到 MySQL Server 后，MySQL Server 會根據用戶的權限來判斷用戶具體可執行哪些操作。

2.2 服務層

MySQL 服務層的東西主要有六方面，我們來逐個分析。

2.2.1 系統管理和控制工具

• 數據庫備份和恢復
• 數據庫安全管理，如用戶及權限管理
• 數據庫復制管理
• 數據庫集群管理
• 數據庫分區，分庫，分表管理
• 數據庫元數據管理

2.2.2 連接池

這個前面已經提到過，連接池負責存儲和管理客戶端與數據庫的連接，一個線程管理一個連接。

2.2.3 SQL 接口

SQL 接口用來接受客戶端發送來的各種 SQL 命令，并且返回用戶需要的查詢結果。

如：

• DDL
• DML
• 存儲過程
• 視圖
• 觸發器

等都在這里被處理。

2.2.4 解析器

解析器的作用主要是解析查詢語句，將客戶端請求的 SQL 解析生成一個“解析樹”，然后根據 MySQL 的語法規則檢查解析樹是否合法，如果語句語法有錯誤，則返回相應的錯誤信息。

語法檢查通過后，解析器會查詢緩存，如果緩存中有對應的語句，就直接返回結果不進行接下來的優化執行操作。

2.2.5 查詢優化器

看名字就知道，這一步主要在解析器完成解析并對 SQL 語法進行檢查之后，對查詢語句進行優化，主要的優化方式包括選擇合適的索引以及數據讀取方式。

2.2.6 緩存

包括全局和引擎特定的緩存，提高查詢的效率。如果查詢緩存中有命中的查詢結果，則查詢語句就可以從緩存中取數據，無須再通過解析和執行。這個緩存機制是由一系列小緩存組成，如表緩存、記錄緩存、key 緩存、權限緩存等。

2.3 存儲引擎層

存儲引擎負責 MySQL 中數據的存儲與提取，與底層系統文件進行交互。

MySQL 存儲引擎是可插拔的，服務器中的查詢執行引擎通過接口與存儲引擎進行通信，接口屏蔽了不同存儲引擎之間的差異。現在有很多種存儲引擎，各有各的特點，最常見的是 MyISAM 和 InnoDB。

需要注意的是，MySQL 存儲引擎是針對數據表而不是針對數據庫，換句話說，在同一個數據庫中，我們可以同時使用多種不同的存儲引擎(技術上可以，實際不推薦)。

3、小結

MySQL 的這種分層設計為我們屏蔽了很多底層的東西，例如存儲引擎的具體工作機制很多時候對開發工程師而言就是透明的，我們不需要關系 InnoDB 怎么工作的，寫好自己的 SQL 就行(個別存儲引擎支持的 SQL 也有差異，這個另論)，這樣對開發工程師來說是更加友好了。

好啦，今天就和小伙伴們先扯這么多～

參考資料： 

• https://zhuanlan.zhihu.com/p/43736857
• https://juejin.cn/post/6857688351168954376

本文轉載自微信公眾號「江南一點雨」，可以通過以下二維碼關注。轉載本文請聯系江南一點雨公眾號。

[[409397]]