假設我們有一條SQL語句是這樣的：

updatet_usersetname='月伴飛魚'whereid=1;

那么我們先想一下這條SQL語句是如何執行的？

首先肯定是我們的系統通過一個數據庫連接發送到了MySQL上，然后肯定會經過SQL接口、解析器、優化器、執行器幾個環節，解析SQL語句，生成執行計劃，接著去由執行器負責這個計劃的執行，調用InnoDB存儲引擎的接口去執行。

大致會走下圖的這個流程

我們就來探索一下這個存儲引擎里的架構設計，以及如何基于存儲引擎完成一條更新語句的執行

緩沖池

InnoDB存儲引擎中有一個非常重要的放在內存里的組件，就是緩沖池（Buffer Pool），這里面會緩存很多的數據， 以便于以后在查詢的時候，萬一你要是內存緩沖池里有數據，就可以不用去查磁盤了

所以當我們的InnoDB存儲 引擎要執行更新語句的時候 ，比如對“id=1”這一行數據，他其實會先將“id=1”這一行數據看看是否在緩沖池里，如果不在的 話，那么會直接從磁盤里加載到緩沖池里來，而且接著還會對這行記錄加獨占鎖。

因為我們想一下，在我們更新“id=1”這一行數據的時候，肯定是不允許別人同時更新的，所以必須要對這行記錄加 獨占鎖

undo日志文件

如何讓你更新的數據可以回滾？

接著下一步，假設“id=1”這行數據的name原來是“周星星”，現在我們要更新為“月伴飛魚”，那么此時我們得先 把要更新的原來的值“周星星”和“id=1”這些信息，寫入到undo日志文件中去。

數據庫中，如果我們執行一個更新語句，要是他是在一個事務里的話，那么事 務提交之前我們都是可以對數據進行回滾的，也就是把你更新為“月伴飛魚”的值回滾到之前的“周星星”去。

所以為了考慮到未來可能要回滾數據的需要，這里會把你更新前的值寫入undo日志文件，我們看下圖。

更新buffer pool中的緩存數據

這里所謂的更新內存緩沖池里的數據，意思就是把內存里的“id=1”這行數據的name字段修改為“月伴飛魚”

當我們把要更新的那行記錄從磁盤文件加載到緩沖池，同時對他加鎖之后，而且還把更新前的舊值寫入undo日志文件 之后，我們就可以正式開始更新這行記錄了，更新的時候，先是會更新緩沖池中的記錄，此時這個數據就是臟數據 了。

那么為什么說此時這行數據就是臟數據了呢？

因為這個時候磁盤上“id=1”這行數據的name字段還是“周星星”，但是內存里這行數據已經被修改了，所以 就會叫他是臟數據。

redo log

接著我們來思考一個問題，按照上圖的說明，現在已經把內存里的數據進行了修改，但是磁盤上的數據還沒修改

那么此時萬一MySQL所在的機器宕機了，必然會導致內存里修改過的數據丟失，這可怎么辦呢？這個時候，就必須要把對內存所做的修改寫入到一個Redo Log Buffer里去，這也是內存里的一個緩沖區，是用來存 放redo日志的

所謂的redo日志，就是記錄下來你對數據做了什么修改，比如對“id=1這行記錄修改了name字段的值為“月伴飛魚”，這 就是一個日志。我們先看下圖

這個redo日志其實是用來在MySQL突然宕機的時候，用來恢復你更新過的數據的

提交事務的時候將redo日志寫入磁盤中

接著我們想要提交一個事務了，此時就會根據一定的策略把redo日志從redo log buffer里刷入到磁盤文件里去。

此時這個策略是通過innodb_flush_log_at_trx_commit來配置的，他有幾個選項。當這個參數的值為0的時候，那么你提交事務的時候，不會把redo log buffer里的數據刷入磁盤文件的，此時可能你都 提交事務了，結果mysql宕機了，然后此時內存里的數據全部丟失。相當于你提交事務成功了，但是由于MySQL突然宕機，導致內存中的數據和redo日志都丟失了

當這個參數的值為1的時候，你提交事務的時候，就必須把redo log從內存刷入到磁盤文件里去，只要事務提交成功，那么redo log就 必然在磁盤里了

那么只要提交事務成功之后，redo日志一定在磁盤文件里，此時你肯定會有一條redo日志說了，“我此時對哪個數據做了一個什么修 改，比如name字段修改為月伴飛魚了”。

然后哪怕此時buffer pool中更新過的數據還沒刷新到磁盤里去，此時內存里的數據是已經更新過的“name=月伴飛魚”，然后磁盤上的數 據還是沒更新過的“name=周星星”。

此時如果說提交事務后處于上圖的狀態，然后mysql系統突然崩潰了，此時會如何？會丟失數據嗎？

肯定不會啊，因為雖然內存里的修改成name=月伴飛魚的數據會丟失，但是redo日志里已經說了，對某某數據做了修改 name=月伴飛魚。

所以此時mysql重啟之后，他可以根據redo日志去恢復之前做過的修改

最后來看看，如果innodb_flush_log_at_trx_commit參數的值是2呢？

他的意思就是，提交事務的時候，把redo日志寫入磁盤文件對應的os cache緩存里去，而不是直接進入磁盤文件，可 能1秒后才會把os cache里的數據寫入到磁盤文件里去。

這種模式下，你提交事務之后，redo log可能僅僅停留在os cache內存緩存里，沒實際進入磁盤文件，萬一此時你要 是機器宕機了，那么os cache里的redo log就會丟失，同樣會讓你感覺提交事務了，結果數據丟了

三種redo日志刷盤策略到底選擇哪一種？

innodb_flush_log_at_trx_commit=0提交事務的時候，不會將內存中的redo log刷入磁盤

優點，純內存操作速度快，缺點，redo日志沒有落地磁盤，如果提交事務的一瞬間，MySQL宕機，那么如果是修改數據，內存數據沒了，磁盤也沒來的及更新，就丟失了本次修改操作。

innodb_flush_log_at_trx_commit=1，提交事務之前一定會將redo log 刷入磁盤

優點，事務提交之前，事務操作log一定刷入磁盤，事務成功，磁盤一定有redo日志，如果事務提交成功，內存修改，磁盤還沒有更新，完全可以讀取redo日志恢復數據。缺點，寫磁盤確實會消耗很多性能，如果是高并發，大量寫入，一定會影響寫入性能，吞吐量和處理時間都會影響到。

innodb_flush_log_at_trx_commit=2，將redo日志刷入OS cache，間隔可能一秒寫入磁盤。方案鑒于一和二方案之間。

優點，利用OS cache去緩存部分日志，可以提高吞吐量，間隔時間，異步刷入磁盤。缺點，提交事務之后，可能redo日志還在cache中。此時，日志存在丟失的風險。

三種方案，第一種方案適用于，允許不重要的數據，但是大批量插入的場景，可能丟失，比如一些大批量的任務執行日志上報的數據。

方案二適用于數據不可丟失的插入更新，比如訂單，用戶等核心數據。

方案三，適用于高并發插入，允許一定數據丟失，但是大部分可靠的場景，比如用戶行為日志，APP異常上報等。

一般建議redo日志刷盤策略設置為1，保證事務提交之后，數據絕對不能丟失，MySQL中這個參數默認值為1

責任編輯人：CC