三大日志
日志分為二類
邏輯日志：可以簡單理解為記錄的就是sql語句。
物理日志：因為mysql數據最終是保存在數據頁中的，物理日志記錄的就是數據頁變更。
undo log
undo log 記錄數據被修改前的樣子
作用
防止丟失數據，用于事務失敗后的回滾
存儲引擎的最大特點就是支持事務，如果本次更新失敗，那么該事務中的所有的操作都必須回滾到執行前的樣子，也就是說當事務失敗的時候，也不會對原始數據有影響
記錄時機
在mysql將要更新的數據加載到緩沖區 pool 時，同時往 undo 日志文件中插入一條日志，也就是將 id=1 的這條記錄的原來的值記錄下來。
更新過程 準備更新一條 SQL 語句MySQL（）會先去緩沖池（）中去查找這條數據，沒找到就會去磁盤中查找，如果查找到就會將這條數據加載到緩沖池（）中在加載到 Pool 的同時，會將這條數據的原始記錄保存到 undo 日志文件中
到這一步，我們的執行的 SQL 語句已經被加載到 Pool 中了，然后開始更新這條語句，更新的操作實際是在 Pool中執行的，那問題來了，按照我們平時開發的一套理論緩沖池中的數據和數據庫中的數據不一致時候，我們就認為緩存中的數據是臟數據日志記錄緩沖區多大好，那此時 Pool 中的數據豈不是成了臟數據？沒錯，目前這條數據就是臟數據， Pool 中的記錄是小強 數據庫中的記錄是旺財 ，這種情況 MySQL是怎么處理的呢，繼續往下看
redo log 簡介
redo 記錄的是數據修改之后的值，不管事務是否提交都會記錄下來
為什么需要redo log 刷入磁盤時機
刷磁盤可以通過 參數來設置
一般情況下，redo log 數據寫入磁盤的策略是立即刷入磁盤
如果 redo log 刷入磁盤后，數據庫服務器宕機了，在下次重啟的時候 MySQL 也會將 redo 日志文件內容恢復到 Pool 中，因為 redo log 中的數據已經被寫入到磁盤了，已經被持久化了
（ Redis 的持久化機制類似，在 Redis 啟動的時候會檢查 rdb 或者是 aof 或者是兩者都檢查，根據持久化的文件來將數據恢復到內存中）
redo log持久化到磁盤前后區別
mysql服務器宕機，緩沖區的數據會怎么樣？
更新過程
截至目前，我們應該都熟悉了 MySQL 的執行器調用存儲引擎是怎么將一條 SQL 加載到緩沖池和記錄哪些日志的，流程如下：
準備更新一條 SQL 語句MySQL（）會先去緩沖池（）中去查找這條數據，沒找到就會去磁盤中查找，如果查找到就會將這條數據加載到緩沖池（）中在加載到 Pool 的同時，會將這條數據的原始記錄保存到 undo 日志文件中 會在 Pool 中執行更新操作，更新后的數據會記錄在 redo log 中將 redo log 中的數據寫入到 redo log 磁盤文件中( 參數決定)提交事務，數據修改永久保存到數據庫 全過程
到此為止，從執行器開始調用存儲引擎接口做了哪些事情呢？
準備更新一條 SQL 語句MySQL（）會先去緩沖池（）中去查找這條數據，沒找到就會去磁盤中查找，如果查找到就會將這條數據加載到緩沖池在加載到 Pool 的同時，會將這條數據的原始記錄保存到 undo 日志文件中 會在 Pool 中執行更新操作，更新后的數據會記錄在 redo log 中MySQL 提交事務的時候，會將 redo log 中的數據寫入到 redo 日志文件中 myslq 宕機重啟的時候會將 redo 日志恢復到緩沖池中 bin log 簡介
用于記錄數據庫執行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。
是通過追加的方式進行寫入的，可以通過參數設置每個文件的大小，當文件大小達到給定值之后，會生成新的文件來保存日志。
使用場景
在實際應用中，的主要使用場景有兩個，分別是主從復制和數據恢復。
主從復制：在端開啟，然后將發送到各個Slave端，Slave端重放從而達到主從數據一致。數據恢復：通過使用工具來恢復數據。 bin log刷入磁盤策略
bin log 的刷盤是有相關的策略的，通過 log來修改
對于存儲引擎而言，只有在事務提交時才會記錄，此時記錄還在內存中，那么是什么時候刷到磁盤中的呢？mysql通過參數控制的刷盤時機，取值范圍是0-N：
刷入 bin log 有以下幾種模式
基于 SQL 語句的復制，每一條會修改數據的 SQL 語句會記錄到 bin log 中
**【優點】：**不需要記錄每一行的變化，減少了 bin log 日志量，節約了 IO , 從而提高了性能
【缺點】：在某些情況下會導致主從數據不一致，比如執行()、sleep()等
基于行的復制(row-based , RBR)，不記錄每條SQL語句的上下文信息，僅需記錄哪條數據被修改了
【優點】：不會出現某些特定情況下的存儲過程、或 、或 的調用和觸發無法被正確復制的問題
【缺點】：會產生大量的日志，尤其是 alter table 的時候會讓日志暴漲
bin log是在什么時候記錄數據的呢？
其實 MySQL 在提交事務的時候日志記錄緩沖區多大好，
不僅僅會將 redo log 中的數據寫入到redo log 文件中，同時也會將本次修改的數據記錄到 bin log文件中，也會將本次修改的bin log文件名和修改的內容在bin log中的位置記錄到redo log中，最后還會在redo log最后寫入 標記，表示**事務成功提交**了
如果在數據被寫入到bin log文件的時候，剛寫完，數據庫宕機了，數據會丟失嗎？
玩來玩去數據還是在內存里，我們數據庫的數據最后是要被持久化要磁盤里的，什么時候持久化？
其實 MySQL 會有一個后臺線程，它會在某個時機將我們 Pool中的臟數據刷到 MySQL 數據庫中，這樣就將內存和數據庫的數據保持統一了
redo日志與bin日志的區別 性質redo Log
文件大小
redo log 的大小是固定的（配置中也可以設置，一般默認的就足夠了）
bin log 可通過配置參數 設置每個bin log文件的大小（但是一般不建議修改）。
實現方式
redo log是引擎層實現的（也就是說是 存儲引起過獨有的）
bin log是 MySQL 層實現的，所有引擎都可以使用 bin log日志
記錄方式
redo log 采用循環寫的方式記錄，當寫到結尾時，會回到開頭循環寫日志。
bin log 通過追加的方式記錄，當文件大小大于給定值后，后續的日志會記錄到新的文件上
使用場景
redo log適用于崩潰恢復(crash-safe)（這一點其實非常類似與 Redis 的持久化特征）
bin log 適用于主從復制和數據恢復
本文總結 準備更新到事務提交全過程
從準備更新一條數據到事務的提交的流程描述
首先執行器根據 更新sql，來查詢滿足條件的數據，先是從緩存池中查詢數據，如果沒有就會去數據庫中查詢，如果查詢到了就將其放到緩存池中在數據被緩存到緩存池的同時，將原始數據寫入 undo log 日志文件在 中更新數據，將更新后的數據添加到 redo log 中完成以后就可以提交事務，在提交事務的前會做以下三件事