日志是 mysql 數據庫的重要組成部分内列，記錄著數據庫運行期間各種狀態(tài)信息。mysql日志主要包括錯誤日志背率、查詢日志话瞧、慢查詢日志、事務日志寝姿、二進制日志幾大類交排。作為開發(fā)，我們重點需要關注的是二進制日志( binlog )和事務日志(包括redo log 和 undo log )饵筑，本文接下來會詳細介紹這三種日志埃篓。
binlog
binlog 用于記錄數據庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中翻翩。binlog 是 mysql的邏輯日志都许，并且由 Server 層進行記錄，使用任何存儲引擎的 mysql 數據庫都會記錄 binlog 日志嫂冻。
- 邏輯日志：可以簡單理解為記錄的就是sql語句 胶征。
- 物理日志：mysql 數據最終是保存在數據頁中的，物理日志記錄的就是數據頁變更 桨仿。
binlog 是通過追加的方式進行寫入的睛低，可以通過max_binlog_size 參數設置每個 binlog文件的大小，當文件大小達到給定值之后服傍，會生成新的文件來保存日志钱雷。binlog使用場景在實際應用中， binlog 的主要使用場景有兩個吹零，分別是 主從復制 和 數據恢復 罩抗。
- 主從復制 ：在 Master 端開啟 binlog ，然后將 binlog發(fā)送到各個 Slave 端灿椅， Slave 端重放 binlog 從而達到主從數據一致套蒂。
- 數據恢復 ：通過使用 mysqlbinlog 工具來恢復數據。
binlog刷盤時機
對于 InnoDB 存儲引擎而言茫蛹，只有在事務提交時才會記錄biglog 操刀，此時記錄還在內存中，那么 biglog是什么時候刷到磁盤中的呢婴洼？
mysql 通過 sync_binlog 參數控制 biglog 的刷盤時機骨坑，取值范圍是 0-N：
- 0：不去強制要求，由系統(tǒng)自行判斷何時寫入磁盤柬采；
- 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 )力试，每一條會修改數據的sql語句會記錄到binlog 中 徙邻。
優(yōu)點：不需要記錄每一行的變化，減少了 binlog 日志量畸裳，節(jié)約了 IO , 從而提高了性能缰犁；
缺點：在某些情況下會導致主從數據不一致，比如執(zhí)行sysdate() 怖糊、 slepp() 等 帅容。
ROW：基于行的復制(row-based replication, RBR )，不記錄每條sql語句的上下文信息伍伤，僅需記錄哪條數據被修改了 并徘。
優(yōu)點：不會出現某些特定情況下的存儲過程、或function扰魂、或trigger的調用和觸發(fā)無法被正確復制的問題 麦乞；
缺點：會產生大量的日志，尤其是
alter table的時候會讓日志暴漲MIXED：基于STATMENT 和 ROW 兩種模式的混合復制(mixed-based replication, MBR )阅爽，一般的復制使用STATEMENT 模式保存 binlog 路幸，對于 STATEMENT 模式無法復制的操作使用 ROW 模式保存 binlog
redo log
為什么需要redo log我們都知道，事務的四大特性里面有一個是 持久性 付翁，具體來說就是只要事務提交成功简肴，那么對數據庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態(tài) 百侧。 那么 mysql是如何保證一致性的呢砰识？最簡單的做法是在每次事務提交的時候能扒，將該事務涉及修改的數據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題辫狼，主要體現在兩個方面：
- 因為 Innodb 是以 頁 為單位進行磁盤交互的初斑，而一個事務很可能只修改一個數據頁里面的幾個字節(jié)，這個時候將完整的數據頁刷到磁盤的話膨处，太浪費資源了见秤！
- 一個事務可能涉及修改多個數據頁，并且這些數據頁在物理上并不連續(xù)真椿，使用隨機IO寫入性能太差鹃答！
因此 mysql 設計了 redo log ， 具體來說就是只記錄事務對數據頁做了哪些修改突硝，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)测摔。redo log基本概念
redo log 包括兩部分：一個是內存中的日志緩沖( redo log buffer )，另一個是磁盤上的日志文件( redo logfile)解恰。
mysql 每執(zhí)行一條 DML 語句锋八，先將記錄寫入 redo log buffer，后續(xù)某個時間點再一次性將多個操作記錄寫到 redo log file护盈。這種 先寫日志挟纱，再寫磁盤 的技術就是 MySQL
里經常說到的 WAL(Write-Ahead Logging) 技術。在計算機操作系統(tǒng)中黄琼，用戶空間( user space )下的緩沖區(qū)數據一般情況下是無法直接寫入磁盤的樊销，中間必須經過操作系統(tǒng)內核空間( kernel space )緩沖區(qū)( OS Buffer )。因此脏款， redo log buffer 寫入 redo logfile 實際上是先寫入 OS Buffer 围苫，然后再通過系統(tǒng)調用 fsync() 將其刷到 redo log file
由 binlog 和 redo log 的區(qū)別可知：binlog 日志只用于歸檔船殉，只依靠 binlog 是沒有 crash-safe 能力的鲫趁。但只有 redo log 也不行，因為 redo log 是 InnoDB特有的利虫，且日志上的記錄落盤后會被覆蓋掉挨厚。因此需要 binlog和 redo log二者同時記錄，才能保證當數據庫發(fā)生宕機重啟時糠惫，數據不會丟失疫剃。
undo log
數據庫事務四大特性中有一個是 原子性 ，具體來說就是 原子性是指對數據庫的一系列操作硼讽，要么全部成功巢价，要么全部失敗，不可能出現部分成功的情況。實際上蹄溉， 原子性 底層就是通過 undo log 實現的咨油。undo log主要記錄了數據的邏輯變化，比如一條 INSERT 語句柒爵，對應一條DELETE 的 undo log 役电，對于每個 UPDATE 語句，對應一條相反的 UPDATE 的 undo log 棉胀，這樣在發(fā)生錯誤時法瑟，就能回滾到事務之前的數據狀態(tài)。同時唁奢， undo log 也是 MVCC(多版本并發(fā)控制)實現的關鍵霎挟。
