一.redo log
使用原因
原理
二.binlog(歸檔日志)
與redo log的差別
三.兩段送出
update T set c=c+1 where ID=2;
執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜尋找到這一行。如果 ID=2 這一行所在的資料頁本來就在記憶體中，就直接傳回給執行器;否則，需要先從磁 盤讀入記憶體，然後再傳回。
執行器拿到引擎給的行資料，把這個值加上 1，比如原來是 N，現在就是 N+1，得到 新的一行資料，再調用引擎接口寫入這行新資料。
引擎将這行新資料更新到記憶體中，同時将這個更新操作記錄到 redo log 裡面，此時 redo log 處于 prepare 狀态(處于prepare狀态之後要寫入磁盤中,但是redo log的commit得辨別為沒有commit)。然後告知執行器執行完成了，随時可以送出事務。
執行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
執行器調用引擎的送出事務接口，引擎把剛剛寫入的 redo log 改成送出(commit)狀态，更新完成。
淺色框表示是在 InnoDB 内部執行的， 深色框表示是在執行器中執行的。
必要性
在兩階段送出的不同時刻，MySQL 異常重新開機會出現什麼現象。
如果在圖中時刻 A 的地方，也就是寫入 redo log 處于 prepare 階段之後、寫 binlog 之 前，發生了崩潰(crash)，由于此時 binlog 還沒寫，redo log 也還沒送出，是以崩潰恢複的時候，這個事務會復原。這時候，binlog 還沒寫，是以也不會傳到備庫。
在時刻 B，也就是 binlog 寫完，redo log 還沒 commit 前發生 crash，那崩潰恢複的時候 MySQL 會怎麼處理 ?
時刻 B 發生 crash 對應的就是 2(a) 的情況，崩潰恢複過程中事務會被送出。
四.binlog寫入機制
其實，binlog 的寫入邏輯比較簡單:事務執行過程中，先把日志寫到 binlog cache，事 務送出的時候，再把 binlog cache 寫到 binlog 檔案中。
一個事務的 binlog 是不能被拆開的，是以不論這個事務多大，也要確定一次性寫入。這 就涉及到了 binlog cache 的儲存問題。
系統給 binlog cache 配置設定了一片記憶體，每個線程一個，參數 binlog_cache_size 用于控 制單個線程内 binlog cache 所占記憶體的大小。如果超過了這個參數規定的大小，就要暫 存到磁盤。
事務送出的時候，執行器把 binlog cache 裡的完整事務寫入到 binlog 中，并清空 binlog cache。狀态如圖 1 所示。
可以看到，每個線程有自己 binlog cache，但是共用同一份 binlog 檔案。
sync_binlog=0 的時候，表示每次送出事務都隻 write，不 fsync;
sync_binlog=1 的時候，表示每次送出事務都會執行 fsync;
sync_binlog=N(N>1) 的時候，表示每次送出事務都 write，但累積 N 個事務後才fsync。
是以，在出現 IO 瓶頸的場景裡，将 sync_binlog 設定成一個比較大的值，可以提升性 能。在實際的業務場景中，考慮到丢失日志量的可控性，一般不建議将這個參數設成 0， 比較常見的是将其設定為 100~1000 中的某個數值。
但是，将 sync_binlog 設定為 N，對應的風險是:如果主機發生異常重新開機，會丢失最近 N 個事務的 binlog 日志。
五.redo log寫入機制
答案是，不需要。 如果事務執行期間 MySQL 發生異常重新開機，那這部分日志就丢了。由于事務并沒有送出， 是以這時日志丢了也不會有損失。
答案是，确實會有, 下面解釋。
這個問題，要從 redo log 可能存在的三種狀态說起。這三種狀态，對應的就是圖 2 中的 三個顔色塊。
存在redo log buffer中,實體上是存在mysql程序記憶體中,就是圖中紅色部分
寫到磁盤(write),但是沒有持久化(fsync),實體上是在檔案系統的page cache裡面,也就是圖中得黃色部分
持久化到磁盤,對應的是hard disk,也就是圖中得綠色部分
日志寫到 redo log buffer 是很快的，wirte 到 page cache 也差不多，但是持久化到磁盤 的速度就慢多了。
設定為 0 的時候，表示每次事務送出時都隻是把 redo log 留在 redo log buffer 中 ;
設定為 1 的時候，表示每次事務送出時都将 redo log 直接持久化到磁盤;
設定為 2 的時候，表示每次事務送出時都隻是把 redo log 寫到 page cache。
實際上，除了背景線程每秒一次的輪詢操作外，還有兩種場景會讓一個沒有送出的事務的 redo log 寫入到磁盤中。
一種是，redo log buffer 占用的空間即将達到 innodb_log_buffer_size 一半的時 候，背景線程會主動寫盤。注意，由于這個事務并沒有送出，是以這個寫盤動作隻是 write，而沒有調用 fsync，也就是隻留在了檔案系統的 page cache。 另一種是，并行的事務送出的時候，順帶将這個事務的 redo log buffer 持久化到磁 盤。假設一個事務 A 執行到一半，已經寫了一些 redo log 到 buffer 中，這時候有另 外一個線程的事務 B 送出，如果 innodb_flush_log_at_trx_commit 設定的是 1，那麼 按照這個參數的邏輯，事務 B 要把 redo log buffer 裡的日志全部持久化到磁盤。這時 候，就會帶上事務 A 在 redo log buffer 裡的日志一起持久化到磁盤。
這裡需要說明的是，我們介紹兩階段送出的時候說過，時序上 redo log 先 prepare， 再 寫 binlog，最後再把 redo log commit。
通常我們說 MySQL 的“雙 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都設定成 1。也就是說，一個事務完整送出前，需要等待兩次刷盤，一次是 redo log(prepare 階段)，一次是 binlog。
在“雙 1”配置下,兩階段送出的詳細流程
redo log的prepare write階段,寫入到page cache 裡(redo log prepare) 然後binlog進入write階段,寫入page cache裡(binlog) 然後redo log 的prepare階段,進行持久化fsync操作,持久化到磁盤(redo log prepare) binlog進行持久化階段fsync階段,持久化到磁盤(binlog) commit階段,先将binlog添加commit辨別,再将redo log添加commit辨別,redo log進行write,寫入page cache(commit)
六.組送出
這裡，我需要先和你介紹日志邏輯序列号(log sequence number，LSN)的概念。LSN 是單調遞增的，用來對應 redo log 的一個個寫入點。每次寫入長度為 length 的 redo log， LSN 的值就會加上 length。
LSN 也會寫到 InnoDB 的資料頁中，來確定資料頁不會被多次執行重複的 redo log。關 于 LSN 和 redo log、checkpoint 的關系，我會在後面的文章中詳細展開。
如圖 3 所示，是三個并發事務 (trx1, trx2, trx3) 在 prepare 階段，都寫完 redo log buffer，持久化到磁盤的過程，對應的 LSN 分别是 50、120 和 160。
從圖中可以看到，
trx1 是第一個到達的，會被選為這組的 leader; 等 trx1 要開始寫盤的時候，這個組裡面已經有了三個事務，這時候 LSN 也變成了160; trx1 去寫盤的時候，帶的就是 LSN=160，是以等 trx1 傳回時，所有 LSN 小于等于160 的 redo log，都已經被持久化到磁盤; 這時候 trx2 和 trx3 就可以直接傳回了。
是以，一次組送出裡面，組員越多，節約磁盤 IOPS 的效果越好。但如果隻有單線程壓 測，那就隻能老老實實地一個事務對應一次持久化操作了。
在并發更新場景下，第一個事務寫完 redo log buffer 以後，接下來這個 fsync 越晚調 用，組員可能越多，節約 IOPS 的效果就越好。
為了讓一次 fsync 帶的組員更多，MySQL 有一個很有趣的優化:拖時間。在介紹兩階段 送出的時候，我曾經給你畫了一個圖，現在我把它截過來。
圖中，我把“寫 binlog”當成一個動作。但實際上，寫 binlog 是分成兩步的:
先把 binlog 從 binlog cache 中寫到磁盤上的 binlog 檔案,此時write步驟,寫入作業系統維護的記憶體中,此記憶體是磁盤中檔案系統申請的記憶體; 調用 fsync 持久化。
MySQL 為了讓組送出的效果更好，把 redo log 做 fsync 的時間拖到了步驟 1 之後。也 就是說，上面的圖變成了這樣:
這麼一來，binlog 也可以組送出了。在執行圖 5 中第 4 步把 binlog fsync 到磁盤時，如 果有多個事務的 binlog 已經寫完了，也是一起持久化的，這樣也可以減少 IOPS 的消耗。
不過通常情況下第 3 步執行得會很快，是以 binlog 的 write 和 fsync 間的間隔時間短， 導緻能集合到一起持久化的 binlog 比較少，是以 binlog 的組送出的效果通常不如 redo log 的效果那麼好。
如果你想提升 binlog 組送出的效果，可以通過設定 binlog_group_commit_sync_delay 和binlog_group_commit_sync_no_delay_count 來實作。
binlog_group_commit_sync_delay 參數，表示延遲多少微秒後才調用 fsync; binlog_group_commit_sync_no_delay_count 參數，表示累積多少次以後才調用fsync。
這兩個條件是或的關系，也就是說隻要有一個滿足條件就會調用 fsync。
是以，當 binlog_group_commit_sync_delay 設定為 0 的時候， binlog_group_commit_sync_no_delay_count 也無效了。
之前有同學在評論區問到，WAL 機制是減少磁盤寫，可是每次送出事務都要寫 redo log 和 binlog，這磁盤讀寫次數也沒變少呀?
現在你就能了解了，WAL 機制主要得益于兩個方面:
redo log 和 binlog 都是順序寫，磁盤的順序寫比随機寫速度要快; 組送出機制，可以大幅度降低磁盤的 IOPS 消耗。
七.mysql提升IO性能
可以考慮以下三種方法:
設定 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 參數，減少 binlog 的寫盤次數。這個 方法是基于“額外的故意等待”來實作的，是以可能會增加語句的響應時間，但沒有丢失資料的風險。 将 sync_binlog 設定為大于 1 的值(比較常見是 100~1000)。這樣做的風險是，主 機掉電時會丢 binlog日志。 将 innodb_flush_log_at_trx_commit 設定為 2。這樣做的風險是，主機掉電的時候會丢資料。
我不建議你把 innodb_flush_log_at_trx_commit 設定成 0。因為把這個參數設定成 0， 表示 redo log 隻儲存在沒有生氣啦申請的記憶體中，這樣的話 MySQL 本身異常重新開機也會丢資料，風險太 大。而 redo log 寫到檔案系統的 page cache 的速度也是很快的，是以将這個參數設定 成 2 跟設定成 0 其實性能差不多，但這樣做 MySQL 異常重新開機時就不會丢資料了(因為資料已經寫入了磁盤中檔案系統申請的記憶體中是作業系統維護的記憶體,而不是在mysql申請的記憶體中)，相比之下風險會更小。