一、存儲引擎

上節我們最后說到，SQL 的執行計劃是執行器組件調用存儲引擎的接口來完成的。
那我們可以理解為：MySQL 這個數據庫管理系統是依靠存儲引擎與存放數據的磁盤文件進行交互的。

那么 MySQL 有哪些存儲引擎呢？

主要有 MyISAM、InnoDB、Memory等等。而現在互聯網中，基本都是使用 InnoDB 存儲引擎，所以接下來我將簡單總結自己關于 InnoDB 存儲引擎的學習，比較簡單的介紹 InnoDB 存儲引擎里面的組件。

二、緩沖池

我們現在都知道了，數據庫的數據是存放在磁盤文件中的。
那么，我們每次對表的增刪改查都是直接在磁盤文件里面操作嗎？

答案：不是的！

因為磁盤文件的隨機讀寫的性能是非常差的，如果所有操作都在磁盤中進行，那么就不會有高性能 MySQL 的說法了，MySQL 也不能支持高并發，也不會在互聯網中如此的流行。

這時候要引入 InnoDB 存儲引擎最重要的一個組件，就是緩沖池（Buffer Pool），它是一個非常重要的內存結構。它是內存里面的，憑借著內存非常高性能的讀寫，使得 MySQL 能夠支持高并發。

緩沖池（Buffer Pool） 的使用原理：

我們先復習一下 MySQL 接收請求的過程。

①、MySQL 的工作線程專門監聽數據庫連接池的連接，有連接就獲取連接中的 SQL 語句。
②、然后將 SQL 語句交給 SQL 接口 去處理，SQL 接口里會進行下面的一系列流程。
③、查詢解析器 將 SQL 語句解析成 MySQL 能理解的東西。
④、接著 查詢優化器 去為 SQL 語句制定一套最優的執行計劃。
⑤、執行器 會根據執行計劃去調用存儲引擎的接口。

上面是上篇文章總結到的東西，那么存儲引擎的接口是怎么進行增刪改查的呢？以更新操作為例，其他的同理。
首先，存儲引擎會先判斷更新 SQL 對應的數據行是否在 緩沖池（Buffer Pool） 里面。如果在的話就直接在 緩沖池（Buffer Pool） 里更新數據然后返回；如果不在，則從磁盤文件里讀取數據到 緩沖池（Buffer Pool） 里，然后進行更新操作，最后再返回結果。

三、undo 日志文件

我們都知道，在事務中，事務提交前是可以隨時回滾對數據的更新的。那么是依靠什么來做的呢？

依靠的是 undo 日志文件。

undo 日志文件的使用原理：

更新數據為例：
假如你更新某行 id=100 的數據，將字段 name 由原來的“張三”改為“李四”，那么此時會將 "id=10" 和 “name=張三” 這兩個關鍵信息寫入 undo 日志文件中。
當你事務提交前需要回滾，就會從 undo 日志文件 中找到這兩個關鍵字，然后進行更新操作的回滾。

四、redo log buffer

上面說到，所有的增刪改查操作其實是在緩沖池里面進行的，所以其實對數據的修改并沒有立刻落實到磁盤文件里面。

那么有一個問題：在緩沖池的臟數據刷回磁盤文件中前，MySQL 宕機了怎么辦？
此時 InnoDB 存儲引擎提供了一個非常重要的組件，就是 redo log buffer 組件.，它也是內存里的一塊緩沖區。

redo log buffer 的使用原理：

還是以上面的更新操作為例，當數據更新后，會記錄下數據更新的的關鍵信息，對應的就是 redo 日志，然后寫入 redo log buffer 里。

但是還是會有一個問題，上面說到，redo log buffer 也是在內存里的。那當 MySQL 宕機時，由于內存里的所有數據都會丟失，所以緩沖池的臟數據和 redo log buffer 的日志還是會全部丟失。
這樣會造成一種情況，客戶端收到更新成功的信息了，但是最后數據庫里頭的數據還是沒更新成功。

所以，redo log buffer 還有一個刷盤策略。正常是，當事務提交時，會將 redo log buffer 里的 redo 日志 刷回到磁盤中，這樣就不用擔心，事務提交成功，但是更新數據可能會丟失的問題了。即使在 緩沖池（Buffer Pool） 的臟數據刷回磁盤前， MySQL 宕機了，也不會丟失數據，因為 MySQL 重啟時可以根據磁盤中的 redo 日志 恢復之前所有臟數據的更新。

總結

以上所述是小編給大家介紹的MySQL 學習總結 之 初步了解 InnoDB 存儲引擎的架構設計，希望對大家有所幫助！