又是被自己菜醒的一天，總結面經看到這題目聽都沒聽過，打開百度就像吃飯一樣自然

老規矩，背誦版在文末。點擊閱讀原文可以直達我收錄整理的各大廠面試真題

首先，咱需要明白的是，啥是持久化?

聽起來高大上，換句簡單的話來說，就是把數據寫到磁盤上，也成為落盤。

那為啥要做持久化到磁盤?

目的就是可以在數據丟失后進行恢復，保證數據不丟失。

那么對于 MySQL 來說，只要 binlog 和 redolog 都能正確持久化到磁盤上，就可以保證數據不丟失了。

由此引出文題，不過在講 redolog 之前，我們還是有必要先來說一下 binlog 的持久化操作。

binlog 持久化

這里引入了一個新的概念：binlog cache

從名字就能看出來，binlog cache 其實就是一片內存區域，充當緩存的作用。

每個線程都有自己 binlog cache 區域，在事務運行的過程中，MySQL 會先把日志寫到 binlog cache 中，等到事務真正提交的時候，再統一把 binlog cache 中的數據寫到 binlog 文件中。(binlog cache 有很多個，binlog 文件只有一個!)

事實上，這個從 binlog cache 寫到 binlog 文件中的操作，并不就是落盤操作了，這里僅僅是把 binlog 寫到了文件系統的 page cache 上(這一步對應下圖中的 write 操作)。

簡單解釋下文件系統的 page cache：

CPU 如果要訪問外部磁盤上的文件，需要首先將這些文件的內容拷貝到內存中，由于硬件的限制，從磁盤到內存的數據傳輸速度是很慢的，如果現在物理內存有空余，干嘛不用這些空閑內存來緩存一些磁盤的文件內容呢，這部分用作緩存磁盤文件的內存就叫做 page cache。

很多同學看到這里可能覺得特別特別熟悉，是的，和 CPU 里的高速緩存是不是很像?兩者其實都是利用的局部性原理，只不過高速緩存是 CPU 緩存內存的數據，而 page cache 是內存緩存磁盤的數據，這也體現了操作系統內存層次結構分級的思想。

所以，最后需要把 page cache 中的數據同步到磁盤上，才算真正完成了 binlog 的持久化(這一步對應下圖中的 fsync 操作)。一般情況下，我們認為 fsync 才占磁盤的 IOPS (Input/Output Operations Per Second)

write 和 fsync 的時機，是由參數 sync_binlog 控制的：

• sync_binlog = 0，每次提交事務的時候，只進行 write，不進行 fsync
• sync_binlog = 1候，每次提交事務的時候，執行 write 和 fsync
• sync_binlog = N(N>1)，每次提交事務的時候，執行 write，累積 N 個事務后再執行 fsync

可以看出來，如果業務場景涉及到的 IO 操作很多的話，可以適當增大 sync_binlog 的值，提高性能。但是也存在一定的風險，比如你設置成 100，萬一在第 80 個事務提交的時候數據庫宕機了，那這些事務的 binlog 日志由于沒有執行 fsync，也就丟失了。

redolog 持久化

類比 binlog，在事務執行過程中，binlog 都是存在 binlog cache 中，redolog 也有這樣一塊內存區域，叫作 redolog buffer。

在事務運行的過程中，MySQL 會先把日志寫到 redolog buffer 中，等到事務真正提交的時候，再統一把 redolog buffer 中的數據寫到 redolog 文件中。和 binlog 的落盤操作一樣，這個從 redolog buffer 寫到 redolog 文件中的操作，并不就是落盤操作了，這里僅僅是把 redolog 寫到了文件系統的 page cache 上，最后還需要執行 fsync 才能夠實現真正的落盤。

解釋下 redo log buffer?

在一個事務的更新過程中，日志是要寫多次的。比如下面這個事務：

begin; 
 insert into table1 ... 
 insert into table2 ... 
commit; 

這個事務要往兩個表 table1 和 table2 中插入記錄，為了確保這個事務不被拆開，一次性的完整寫入日志文件中，在插入數據的過程中，我們需要把生成的日志都先保存起來。redolog buffer 就是這么一個用來先存 redo 日志的地方。

也就是說，在執行第一條 insert 語句的時候，redolog buffer 也就寫入了這條記錄的日志。

不同于 binlog cache 每個線程都有一個，redolog buffer 只有那么一個。

事實上，日志寫到 redolog buffer 是很快的，wirte 到 page cache 也差不多，但是 fsync 持久化到磁盤的速度就慢多了，為了控制 redo log 的寫入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 參數，它有三種可能取值：

• innodb_flush_log_at_trx_commit = 0，每次事務提交的時候，都只是把 redolog 留在 redolog buffer 中
• innodb_flush_log_at_trx_commit = 1，每次事務提交的時候，都執行 fsync 將 redolog 直接持久化到磁盤
• innodb_flush_log_at_trx_commit = 2，每次事務提交的時候，都只執行 write 將 redolog 寫到文件系統的 page cache 中
• 說了這么多，各位小伙伴們對 binlog 和 redolog 的持久化機制想必都有所了解了，我們來看文題：事務還沒提交的時候，redolog 能不能被持久化到磁盤呢?

先說答案，答案就是有可能。

分析下 redolog 可能存在的三種狀態(binlog 也差不多)：

• 事務執行過程中，存在 MySQL 的進程內存中的 redolog buffer 中
• 事務提交，執行 write 操作存在文件系統的 page cache 中，但是沒有執行 fsync 操作持久化到磁盤
• 事務提交，執行 fsync 操作持久化到磁盤

至于為什么說事務還沒提交的時候，redolog 也有可能被持久化到磁盤呢?

InnoDB 有一個后臺線程，每隔 1 秒輪詢一次，具體的操作是這樣的：調用 write 將 redolog buffer 中的日志寫到文件系統的 page cache，然后調用 fsync 持久化到磁盤。而在事務執行中間過程的 redolog 都是直接寫在 redolog buffer 中的，也就是說，一個沒有提交的事務的 redolog，也是有可能會被后臺線程一起持久化到磁盤的。

另外，除了后臺線程每秒一次的輪詢操作外，還有兩種場景會讓一個沒有提交的事務的 redolog 寫盤：

• innodb_flush_log_at_trx_commit 設置是 1，這樣并行的某個事務提交的時候，就會順帶將這個事務的 redolog buffer 持久化到磁盤

舉個例子，假設事務 A 執行到一半，已經寫了一些 redolog 到 redolog buffer 中，這時候有另外一個事務 B 提交，按照 innodb_flush_log_at_trx_commit = 1 的邏輯，事務 B 要把 redolog buffer 里的日志全部持久化到磁盤，這時候，就會帶上事務 A 在 redolog buffer 里的日志一起持久化到磁盤

• redo log buffer 占用的空間達到 redolo buffer 大小(由參數 innodb_log_buffer_size 控制，默認是 8MB)一半的時候，后臺線程會主動寫盤。不過由于這個事務并沒有提交，所以這個寫盤動作只是 write 到了文件系統的 page cache，仍然是在內存中，并沒有調用 fsync 真正落盤

最后放上這道題的背誦版：

• 面試官：
• 問題：事務還沒提交的時候，redo log 能不能被持久化到磁盤呢?

相關問題：MySQL 是如何保證數據不丟失的呢?

 小牛肉：事務還沒有提交的時候，redo log 是有可能被持久化到磁盤的。

redolog 的具體落盤操作是這樣的：在事務運行的過程中，MySQL 會先把日志寫到 redolog buffer 中，等到事務真正提交的時候，再統一把 redolog buffer 中的數據寫到 redolog 文件中。不過這個從 redolog buffer 寫到 redolog 文件中的操作也就是 write 并不就是落盤操作了，這里僅僅是把 redolog 寫到了文件系統的 page cache 上，最后還需要執行 fsync 才能夠實現真正的落盤。

也就是說，redolog 其實存在三種狀態：

• 事務執行過程中，存在 MySQL 的進程內存中的 redolog buffer 中
• 事務提交，執行 write 操作存在文件系統的 page cache 中，但是沒有執行 fsync 操作持久化到磁盤
• 事務提交，執行 fsync 操作持久化到磁盤

額為什么說事務還沒提交的時候，redolog 也有可能被持久化到磁盤呢?

主要有三種可能的原因：

• 第一種情況：InnoDB 有一個后臺線程，每隔 1 秒輪詢一次，具體的操作是這樣的：調用 write 將 redolog buffer 中的日志寫到文件系統的 page cache，然后調用 fsync 持久化到磁盤。而在事務執行中間過程的 redolog 都是直接寫在 redolog buffer 中的，也就是說，一個沒有提交的事務的 redolog，也是有可能會被后臺線程一起持久化到磁盤的。
• 第二種情況：innodb_flush_log_at_trx_commit 設置是 1，這個參數的意思就是，每次事務提交的時候，都執行 fsync 將 redolog 直接持久化到磁盤(還有 0 和 2 的選擇，0 表示每次事務提交的時候，都只是把 redolog 留在 redolog buffer 中;2 表示每次事務提交的時候，都只執行 write 將 redolog 寫到文件系統的 page cache 中)。舉個例子，假設事務 A 執行到一半，已經寫了一些 redolog 到 redolog buffer 中，這時候有另外一個事務 B 提交，按照 innodb_flush_log_at_trx_commit = 1 的邏輯，事務 B 要把 redolog buffer 里的日志全部持久化到磁盤，這時候，就會帶上事務 A 在 redolog buffer 里的日志一起持久化到磁盤
• 第三種情況：redo log buffer 占用的空間達到 redolo buffer 大小(由參數 innodb_log_buffer_size 控制，默認是 8MB)一半的時候，后臺線程會主動寫盤。不過由于這個事務并沒有提交，所以這個寫盤動作只是 write 到了文件系統的 page cache，仍然是在內存中，并沒有調用 fsync 真正落盤