mysql的幾種日誌工作原理
redo log
InnoDB引擎層日誌，屬於物理日誌，從5.5.5版本開始加入，記錄每次操作的行爲，用於宕機恢復。它的空間是固定的， 所以會用完。
binlog
server層日誌，採用增量寫入方式，主要用於備份數據庫或恢復數據庫
undo log
回滾日誌，用於事務提交失敗回滾或其他錯誤回滾。
redo log和binlog的兩階段提交：
在update操作中，server層的執行器先找引擎層，用查詢操作找到要修改的數據，然後用行鎖鎖定這一行數據（mysql8.0之前可以不調用執行器，先從內存緩存中取數據，如果沒找到再找引擎層。8.0之後刪除了內存緩存不會有這一步)。
然後
1.準備好redo log， redo log 處於 prepare 狀態。
2.執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。
3.執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。
當在2之前崩潰時
重啓恢復：後發現沒有commit，回滾。備份恢復：沒有binlog 。一致
當在3之前崩潰時
重啓恢復：雖沒有commit，但滿足prepare和binlog完整，所以重啓後會自動commit。備份：有binlog. 一致
我們假象沒有這兩個階段提交，會有什麼後果?
第一步直接提交redo log，寫數據，第二部生成bin log ，完成更新操作。
如果服務在第一步後宕機了，那麼數據被成功寫入，而bin log中不存在對此次操作的記錄，在主從同步或者是恢復數據庫時就會丟失這一條數據。數據丟失很嚴重的大兄嘚，所以需要兩段提交。