一條更新SQL的內部執行
學習MySQL實戰45講，非常推薦學
還是老圖：
上文複習
在執行查詢語句的時候，會執行連接器(總要連上才能搞事情)，然後去查詢緩存(MySQL8+刪除了)，有數據返回，沒數據進行分析器-優化器-執行器-執行引擎流程並且其特點是如果該表上有更新，都會把緩存結果清空；
MySQL整體來看可以分爲兩塊：一塊是Server層，它主要做的是MySQL功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜；
update T set c=c+1 where ID=2;
流程：
- 連接器：連接數據庫
- 分析器：分析詞法和語法解析知道這是更新語句
- 優化器：決定使用ID進行索引
- 執行器：具體執行，找到改行然後更新
更新對查詢來說，涉及到了兩個重要的日誌模塊,redo log（重做日誌）InnoDB特有的，binlog（歸檔日誌）Server中存在的，只要持續學習數據庫方面，這兩個是繞不過的。
redo log（重做日誌）
在InnoDB中redo log的大小是固定的，可以配置爲一組4個文件，每個文件的大小是1GB，那麼這塊redo log總共就可以記錄4GB的操作(可以自己設置)。
MySQL中的問題：
如果每一次的更新操作都需要寫進磁盤，然後磁盤也要找到對應的那條記錄，然後再更新，整個過程IO成本、查找成本都很高
解決問題：
WAL技術：Write-Ahead Logging
- 寫日誌
- 寫磁盤
執行流程：
爲什麼redo log具有crash-safe的能力
爲什麼 redo log 具有 crash-safe 的能力，是 binlog 無法替代的？
redo log的被動刷盤機制
明確定義：
write：刷盤
fsync：持久化到磁盤
write(刷盤)指的是MySQL從buffer pool中將內容寫到系統的page cache中，並沒有持久化到系統磁盤上。這個速度其實是很快的。
fsync指的是從系統的cache中將數據持久化到系統磁盤上。這個速度可以認爲比較慢，而且也是IOPS升高的真正原因。
redo log是物理日誌，記錄的是“在某個數據頁上做了什麼修改”，內部結構是基於頁的，記錄了這個頁的字段值變化，只要crash後讀取redo log進行重放就可以恢復數據。（因爲redo log是循環寫的，如果滿了InnoDB就會執行真正寫盤）。
好處是不用每一次操作都實時把數據寫盤，就算crash後也可以通過redo log重放恢復，所以能夠實現快速響應SQL語句。
binlog（歸檔日誌）
MySQL剛開始是使用的自帶引擎MyISAM,但其沒有crash-safe,binlog日誌只能用於歸檔，5.5版本之後引入InnoDB,通過redo log來實現crash-safe能力。
redo log與binlog的區別
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。
- redo log 是
物理日誌，記錄的是在某個數據頁上做了什麼修改；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”。 - redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指 binlog 文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌
update內部執行流程：
流程圖：圖中淺色框表示是在 InnoDB 內部執行的，深色框表示是在執行器中執行的
其中redo log分爲兩個階段提交：這是爲了讓兩份日誌之間的邏輯一致
- redo log prepare階段
- commit階段
好處：保證redo log和binlog都能同時失敗或者成功。
論證兩階段提交的必要性：
如果不採用兩階段提交，那麼redo log和binlog是單獨的邏輯，由此引出下面兩種提交方式：
- 先寫redo log,後寫binlog
- 先寫binlog,後寫redo log
還是以update爲例：
update T set c=c+1 where ID=2;
先寫redo log,後寫binlog
在redo log寫完，binlog沒寫完的時候，MySQL 進程異常重啓，因爲其實先寫入內存的，所以MySQL崩潰後仍然能把數據恢復
根據備份恢復後c的值爲1.但由於binlog沒有寫完就崩潰了，這時候binlog就沒有記錄這條語句的操作，使用binlog恢復的時候就會少一次更新，c的值爲0，這就與原庫的值不同了。
先寫binlog,後寫redo log與上面邏輯相同都會造成恢復的數據與原庫值不同；
可以看到，如果不使用“兩階段提交”，那麼數據庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致
但是當按照上述流程圖來說，在進行兩階段提交的時候，即A、B時刻出現crash,是怎麼處理的。
流程如下：
B時刻發生crash後對應的是2(a)的情況，崩潰恢復過程中事務會被提交。
由此引出的很多問題，感興趣的朋友可以看下MySQL實戰45講答疑篇第一章
備份的流程：
- 找到最近的一次全量備份，從這個備份恢復到臨時庫；
- 從備份的時間點開始，將備份的 binlog 依次取出來，重放到中午誤刪表之前的那個時刻。
備份恢復的數據的場景：
- 誤操作後需要恢復數據
- 要擴容的時候，也需要再多搭建一些備庫來增加系統的讀能力的時候，用全量備份加上應用binlog 來實現的。如果這個“不一致”就會導致你的線上出現主從數據庫不一致的情況