Mysql實戰45講學習詳情----一條SQL更新語句是如何執行的？

相關詞語：

　　redo log：日誌模塊（臨時記錄，相似於便籤），InnoDB 引擎特有日誌

　　WAL（Write-Ahead Logging）：寫入方式

　　binlog：日誌模塊（歸檔日誌），Server 層的日誌

　　crash-safe：redo log帶來的好處（MySQL 能夠恢復到固定時間內任意一秒的狀態）

 

WAL執行過程（redo log日誌的存儲方式）：

　

 

write pos 是當前記錄的位置，checkpoint 是當前要擦除的位置，它們之間的是「便籤」上還空着的部分。若是 write pos 追上 checkpoint，表示「粉板」滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推動一下。

redo log 與binlog的不一樣點：

　　redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，全部引擎均可以使用。

　　redo log 是物理日誌，記錄的是「在某個數據頁上作了什麼修改」；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯，好比「給 ID=2 這一行的 c 字段加 1 」。

　　redo log 是循環寫的，空間固定會用完；binlog 是能夠追加寫入的。「追加寫」是指 binlog 文件寫到必定大小後會切換到下一個，並不會覆蓋之前的日誌。

首先update語句會把查詢語句的流程先走一遍，區別就在與涉及到的兩個日誌模塊：

　　update T set c=c+1 where ID=2;

　　1.鏈接數據庫（鏈接器工做）

　　2.清空查詢緩存（查詢緩存工做）--》更新語句會清空更新表的查詢緩存

　　3.分析詞法和語法（分析器工做）--》獲得這是一條更新語句

　　4.優化器決定使用ID這個索引（優化器工做）--》決定執行方案

　　5.執行器開始執行（執行器工做）--》找到這一行，進行更新

　　更新過程當中，執行器與引擎的交互：

　　　　

　　　　　　此處將redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"。

爲何須要「兩階段提交「呢？

是爲了讓兩份日誌之間的邏輯保持一致。

　　這裏就能夠說說crash-safe功能是怎麼實行的了。

　　crash-safe（例如）：怎樣讓數據庫恢復到半個月內任意一秒的狀態？

　　binlog 會記錄全部的邏輯操做，而且是採用「追加寫」的形式。若是須要半個月內能夠恢復，那麼備份系統中必定會保存最近半個月的全部 binlog，同時系統會按期作整庫備份。這裏的「按期」取決於系統的重要性，能夠是一天一備，也能夠是一週一備。

 　　　　當須要恢復到指定的某一秒時，好比某天下午兩點發現中午十二點有一次誤刪表，須要找回數據，那你能夠這麼作：

　　　　　　1.找到最近的一次全量備份

　　　　　　2.從這個備份恢復到臨時庫

　　　　　　3.從備份的時間點開始，將備份的 binlog 依次取出來，重放到中午誤刪表以前的那個時刻。

　　而redo log 和 binlog 是兩個獨立的邏輯，若是不用兩階段提交，要麼就是先寫完 redo log 再寫 binlog，或者採用反過來的順序。咱們看看這兩種方式會有什麼問題。

　　　　①，先寫 redo log 後寫 binlog。

　　　　　　假設在 redo log 寫完，binlog 尚未寫完的時候，MySQL 進程異常重啓。因爲咱們前面說過的，redo log 寫完以後，系統即便崩潰，仍然可以把數據恢復回來，因此恢復後這一行 c 的值是 1。可是因爲 binlog 沒寫完就 crash 了，這時候 binlog 裏面就沒有記錄這個語句。所以，以後備份日誌的時候，存起來的 binlog 裏面就沒有這條語句。而後你會發現，若是須要用這個 binlog 來恢復臨時庫的話，因爲這個語句的 binlog 丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行 c 的值就是 0，與原庫的值不一樣。

　　　　②，先寫 binlog 後寫 redo log。

　　　　　　若是在 binlog 寫完以後 crash，因爲 redo log 還沒寫，崩潰恢復之後這個事務無效，因此這一行 c 的值是 0。可是 binlog 裏面已經記錄了「把 c 從 0 改爲 1」這個日誌。因此，在以後用 binlog 來恢復的時候就多了一個事務出來，恢復出來的這一行 c 的值就是 1，與原庫的值不一樣。

　　簡單說，redo log 和 binlog 均可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。

總結：

　　redo log 用於保證 crash-safe 能力。

　　nnodb_flush_log_at_trx_commit 這個參數設置成 1 的時候，表示每次事務的 redo log 都直接持久化到磁盤。（能夠保證 MySQL 異常重啓以後數據不丟失）

　　sync_binlog 這個參數設置成 1 的時候，表示每次事務的 binlog 都持久化到磁盤。（能夠保證 MySQL 異常重啓以後 binlog 不丟失）

　　兩階段提交是跨系統維持數據邏輯一致性時經常使用的一個方案，即便你不作數據庫內核開發，平常開發中也有可能會用到。　　　

【附加問題】

　　按期全量備份的週期「取決於系統重要性，有的是一天一備，有的是一週一備」。那麼在什麼場景下，一天一備會比一週一備更有優點呢？或者說，它影響了這個數據庫系統的哪一個指標？

【我的理解】

　　首先我理解的數據備份是爲了恢復數據，假如須要恢復的是上週的數據，那麼一週一備份就須要整週全備+須要恢復的數據時間點binlog來恢復，一天一備的話只須要當天的全備+這天某個時間段的binlog來恢復，那麼一天已備份的優點就在於恢復丟失數據時的工做量。

　　其次就是數據丟失時的確認時間，天備只須要確認當天的binlog無缺無損，而周備須要確認一整週的binlog無缺。