一條更新語句執行的順序
update T set c=c+1 where ID=2;
a. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜尋找到這一行。如果 ID=2 這一行所在的資料頁本來就在記憶體中，就直接傳回給執行器；否則，需要先從磁盤讀入記憶體，然後再傳回。
b. 執行器拿到引擎給的行資料，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行資料，再調用引擎接口寫入這行新資料。
c. 引擎将這行新資料更新到記憶體中，同時将這個更新操作記錄到 redo log 裡面，此時 redo log 處于 prepare 狀态。然後告知執行器執行完成了，随時可以送出事務。
d. 執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
e. 執行器調用引擎的送出事務接口，引擎把剛剛寫入的 redo log 改成送出（commit）狀态，更新完成。
1.binlog
binlog屬于MySQL Server層面，稱為歸檔日志，以二進制形式記錄語句的原始邏輯，binlog是沒有crash-safe能力
binlog
用于記錄資料庫執行的寫入性操作(不包括查詢)資訊，以二進制的形式儲存在磁盤中。
binlog
是
mysql
的邏輯日志，并且由
Server
層進行記錄，使用任何存儲引擎的
mysql
資料庫都會記錄
binlog
日志。
- 邏輯日志：可以簡單了解為記錄的就是sql語句 。
- 實體日志：
mysql
binlog
是通過追加的方式進行寫入的，可以通過
max_binlog_size
參數設定每個
binlog
檔案的大小，當檔案大小達到給定值之後，會生成新的檔案來儲存日志。
binlog 使用場景
在實際應用中，
binlog
的主要使用場景有兩個，分别是 主從複制 和 資料恢複 。
- 主從複制 ：在
Master
binlog
binlog
Slave
Slave
binlog
- 資料恢複 ：通過使用
mysqlbinlog
binlog 刷盤時機
對于
InnoDB
存儲引擎而言，隻有在事務送出時才會記錄
biglog
，此時記錄還在記憶體中，那麼
biglog
是什麼時候刷到磁盤中的呢？
mysql
通過
sync_binlog
參數控制
biglog
的刷盤時機，取值範圍是
0-N
：
- 0：不去強制要求，由系統自行判斷何時寫入磁盤；
- 1：每次
commit
binlog
- N：每N個事務，才會将
binlog
從上面可以看出，
sync_binlog
最安全的是設定是
1
，這也是
MySQL 5.7.7
之後版本的預設值。但是設定一個大一些的值可以提升資料庫性能，是以實際情況下也可以将值适當調大，犧牲一定的一緻性來擷取更好的性能。
binlog 日志格式
binlog
日志有三種格式，分别為
STATMENT
、
ROW
和
MIXED
。
在之前，預設的格式是MySQL 5.7.7
，STATEMENT
之後，預設值是MySQL 5.7.7
。日志格式通過ROW
指定。binlog-format
-
STATMENT
SQL
statement-based replication, SBR
binlog
中 。
**優點：**不需要記錄每一行的變化，減少了 binlog 日志量，節約了 IO , 進而提高了性能；
**缺點：**在某些情況下會導緻主從資料不一緻，比如執行sysdate() 、 slepp() 等 。
-
ROW
row-based replication, RBR
)，不記錄每條sql語句的上下文資訊，僅需記錄哪條資料被修改了 。
**優點：**不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正确複制的問題 ；
缺點：會産生大量的日志，尤其是
alter table
-
MIXED
STATMENT
ROW
mixed-based replication, MBR
STATEMENT
binlog
STATEMENT
ROW
binlog
2.redo log
2.1為什麼需要redo log
我們都知道，事務的四大特性裡面有一個是 持久性 ，具體來說就是隻要事務送出成功，那麼對資料庫做的修改就被永久儲存下來了，不可能因為任何原因再回到原來的狀态 。
那麼
mysql
是如何保證一緻性的呢？
最簡單的做法是在每次事務送出的時候，将該事務涉及修改的資料頁全部重新整理到磁盤中。但是這麼做會有嚴重的性能問題，主要展現在兩個方面：
- 因為
Innodb
頁
- 一個事務可能涉及修改多個資料頁，并且這些資料頁在實體上并不連續，使用随機IO寫入性能太差！
是以
mysql
設計了
redo log
， 具體來說就是隻記錄事務對資料頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言檔案更小并且是順序IO)。
2.2 redo log 基本概念
每次對記錄的修改寫入緩沖池的時候，先講記錄寫入redo log buffer（記錄着哪一頁修改了什麼資料），後續在特定時刻将多個操作刷盤到redo log file中(放在磁盤)，這種先寫日志，再寫磁盤的技術就是MySQL裡的WAL(Write-Ahead Logging)技術。
在作業系統中，使用者空間下的緩沖區是無法直接寫入磁盤的，中間必須經過作業系統核心空間(kernal space)緩沖區，然後通過系統調用fsync()刷到redo log file中。
MySQL支援三種将redo log buffer寫入redo log file的時機，可以通過 innodb_flush_log_at_trx_commit 參數配置，相關含義如下：
可以發現寫入redo log file也是磁盤IO，但它是順序IO，比從緩沖池将資料頁随機IO到磁盤快很多。
2.3 redo log 記錄形式
在更新一條語句時，InnoDB會把更新記錄寫到redo log中，然後更新記憶體，然後在空閑的時候或是按照設定的更新政策将redo log中的内容更新到磁盤。redo log日志大小是固定的，即記錄滿了後就從頭循環寫。Checkpoint 以前表示已經更新到磁盤的檔案，write pos表示目前寫的位置，如果兩個指針相遇了，表示redo log已經滿了，需要同步到磁盤中。
前面說過，
redo log
實際上記錄資料頁的變更，而這種變更記錄是沒必要全部儲存，是以
redo log
實作上采用了大小固定，循環寫入的方式，當寫到結尾時，會回到開頭循環寫日志。如下圖：
同時我們很容易得知， 在innodb中，既有
redo log
需要刷盤，還有
資料頁
也需要刷盤，
redo log
存在的意義主要就是降低對
資料頁
刷盤的要求 ** 。
在上圖中，
write pos
表示
redo log
目前記錄的
LSN
(邏輯序列号)位置，
check point
表示 資料頁更改記錄 刷盤後對應
redo log
所處的
LSN
(邏輯序列号)位置。
write pos
到
check point
之間的部分是
redo log
空着的部分，用于記錄新的記錄；
check point
到
write pos
之間是
redo log
待落盤的資料頁更改記錄。當
write pos
追上
check point
時，會先推動
check point
向前移動，空出位置再記錄新的日志。
啟動
innodb
的時候，不管上次是正常關閉還是異常關閉，總是會進行恢複操作。因為
redo log
記錄的是資料頁的實體變化，是以恢複的時候速度比邏輯日志(如
binlog
)要快很多。
重新開機
innodb
時，首先會檢查磁盤中資料頁的
LSN
，如果資料頁的
LSN
小于日志中的
LSN
，則會從
checkpoint
開始恢複。
還有一種情況，在當機前正處于
checkpoint
的刷盤過程，且資料頁的刷盤進度超過了日志頁的刷盤進度，此時會出現資料頁中記錄的
LSN
大于日志中的
LSN
，這時超出日志進度的部分将不會重做，因為這本身就表示已經做過的事情，無需再重做。
2.4 redo log和binlog差別
由
binlog
和
redo log
的差別可知：
binlog
日志隻用于歸檔，隻依靠
binlog
是沒有
crash-safe
能力的。
但隻有
redo log
也不行，因為
redo log
是
InnoDB
特有的，且日志上的記錄落盤後會被覆寫掉。是以需要
binlog
和
redo log
二者同時記錄，才能保證當資料庫發生當機重新開機時，資料不會丢失。
3. undo log
資料庫事務四大特性中有一個是 原子性 ，具體來說就是 原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。
實際上， 原子性 底層就是通過
undo log
實作的。
undo log
主要記錄了資料的邏輯變化，比如一條
INSERT
語句，對應一條
DELETE
的
undo log
，對于每個
UPDATE
語句，對應一條相反的
UPDATE
的
undo log
，這樣在發生錯誤時，就能復原到事務之前的資料狀态。
同時，
undo log
也是
MVCC
(多版本并發控制)實作的關鍵。
每條資料修改(insert、update或delete)操作都伴随一條undo log的生成,并且復原日志必須先于資料持久化到磁盤上
Binlog詳解 - 簡書
MySQL 必須掌握的三大日志-binglog、redo log以及undo log_程式員掉頭發的部落格-CSDN部落格_binglog