23 MySQL是怎麼保證資料不丟的？

其實，binlog 的寫入邏輯比較簡單：事務執行過程中，先把日誌寫到 binlog cache，事務提交的時候，再把 binlog cache 寫到 binlog 檔案中。

乙個事務的 binlog 是不能被拆開的，因此不論這個事務多大，也要確保一次性寫入。這就涉及到了 binlog cache 的儲存問題。

系統給 binlog cache 分配了一片記憶體，每個執行緒乙個，引數 binlog_cache_size 用於控制單個執行緒內 binlog cache 所佔記憶體的大小。如果超過了這個引數規定的大小，就要暫存到磁碟。

事務提交的時候，執行器把 binlog cache 裡的完整事務寫入到 binlog 中，並清空 binlog cache。

每個執行緒擁有自己的binlog cache ，但是共用同乙份binlog檔案。

圖中的 write，指的就是指把日誌寫入到檔案系統的 page cache，並沒有把資料持久化到磁碟，所以速度比較快。

圖中的 fsync，才是將資料持久化到磁碟的操作。一般情況下，我們認為 fsync 才佔磁碟的 iops。

write 和 fsync 的時機，是由引數 sync_binlog 控制的：

因此，在出現 io 瓶頸的場景裡，將 sync_binlog 設定成乙個比較大的值，可以提公升效能。在實際的業務場景中，考慮到丟失日誌量的可控性，一般不建議將這個引數設成 0，比較常見的是將其設定為 100~1000 中的某個數值。

但是，將 sync_binlog 設定為 n，對應的風險是：如果主機發生異常重啟，會丟失最近 n 個事務的 binlog 日誌。

binlog儲存是以statement或者row格式儲存的，而redo log是以page頁格式儲存的。page格式，天生就是共有的，而row格式，只跟當前事務相關