一般在我們的後端系統中，和數據庫打交道都邏輯都放在DAO層，DAO層的持久化框架中封裝了：數據驅動（Driver），SQL語句一般也都是由DAO層的持久化框架發送給數據庫的。

是的，通常大家會把數據庫分層兩部分，上層的Server層和下層的存儲引擎層。

總的來看：Server層主要是負責和客戶端建立網絡連接，接受客戶端傳遞過來的SQL、預處理、由執行器發送給儲存引擎執行。

而存儲引擎會和操作系統的文件系統打交道。

我在圖中畫的存儲引擎層是InnoDB，MySQL不止這一種執行引擎，對於MySQL來說存儲引擎是可插拔的。

常見的還有什麼MyISAM、NDB、Memory等等。

我…..

好，我們的應用程序把SQL發送給Server層後，SQL會陸續被分析器、優化器、執行器處理。

另外在圖中你能看到：查詢緩存。這個查詢緩存由Server層維護，它設計的初衷就是在內存中暫存原來查詢的結果。以便下次查詢時可以快速得到結果^_^

但是它有個缺點就是當有對該表的更新操作時，該表的查詢緩存會被廢棄。所以MySQL8中將查詢緩存砍掉了。

嗯嗯，那我繼續往下說。

分析器的作用：對SQL進行語法、詞法上的分析。

優化器的作用：生成執行計劃、選擇索引。

執行器的作用：操作執行引擎，獲取SQL的執行結果。

，可以下看面的Case。

我們的update sql經過server層的分析檢測之後，最終由執行器交由存儲引擎執行。

因為InnoDB是支持事務的，而我們現在是update類型的SQL，所以會被放在一個單獨的事務中去執行。

為了提供事務回滾的能力，於是有了上圖中的第5步，InnoDB存儲引擎會先寫undo log。

寫完undo log之後，整體的執行流程會來到圖中的第6步。

在BufferPool緩存池中對內存中的數據進行update。

嗯，是這樣的。 首先我們都知道，MySQL是支持持久化的，數據最終都落在磁盤上。

但是如果所有的update sql 都直接、大量、頻繁的進行IO磁盤操作，會導致MySQL整體的性能極具下降。

現在MySQL實現方式是：它在內存中對數據進行CRUD，所以在圖中可以看到，BufferPool中的數據是從磁盤上讀進去的。

在內存中CRUD就能獲得最大的性能。後續再通過一定的機制將數據刷新回磁盤中。

當update sql修改完內存中的數據後，接下來就是提交事務了。提交事務的方式一般都是兩階段提交。

也就是：

1、先寫redo log（prepare）

2、寫binlog

3、寫redo log （commit）

這些日誌後續也都會有一定的機制控制把它們持久化到磁盤中。

記錄binlog可以使MySQL就擁有：搭建集群、數據備份、數據恢復、審計的能力啊

寫redolog後MySQL就擁有了崩潰恢復的能力。

嗯～，我是這樣理解的：binlog由MySQL的上層也就是Server層記錄。

可以看下這張圖：截自部分binlog

可以看到binlog中記錄的是sql語句，記錄這你對哪張表的id=xx的行做了什麼樣的修改。

像數據表啊、行啊這都是一些只存在於邏輯上概念。

而redolog中記錄的是物理層面的概念。比如redo log中會記錄你對xxx表空間的XXX數據頁xxx偏移量的地方做了XXX更新。