來源：https://juejin.im/post/6860252224930070536
作者：六點(diǎn)半起床
日志是 mysql 數(shù)據(jù)庫的重要組成部分膜宋，記錄著數(shù)據(jù)庫運(yùn)行期間各種狀態(tài)信息。mysql日志主要包括錯誤日志、查詢?nèi)罩疽霰ā⒙樵內(nèi)罩径荡恰⑹聞?wù)日志迎瞧、二進(jìn)制日志幾大類。作為開發(fā)逸吵，我們重點(diǎn)需要關(guān)注的是二進(jìn)制日志( binlog )和事務(wù)日志(包括
redo log 和 undo log )凶硅，本文接下來會詳細(xì)介紹這三種日志。
binlog
binlog 用于記錄數(shù)據(jù)庫執(zhí)行的寫入性操作(不包括查詢)信息扫皱，以二進(jìn)制的形式保存在磁盤中足绅。binlog 是 mysql的邏輯日志，并且由 Server 層進(jìn)行記錄啸罢，使用任何存儲引擎的 mysql 數(shù)據(jù)庫都會記錄 binlog 日志编检。
邏輯日志：可以簡單理解為記錄的就是sql語句 胎食。
物理日志：
mysql數(shù)據(jù)最終是保存在數(shù)據(jù)頁中的扰才，物理日志記錄的就是數(shù)據(jù)頁變更 。
binlog 是通過追加的方式進(jìn)行寫入的厕怜，可以通過 max_binlog_size 參數(shù)設(shè)置每個 binlog
文件的大小衩匣，當(dāng)文件大小達(dá)到給定值之后，會生成新的文件來保存日志粥航。
binlog使用場景
在實(shí)際應(yīng)用中琅捏， binlog 的主要使用場景有兩個，分別是 主從復(fù)制 和 數(shù)據(jù)恢復(fù) 递雀。
主從復(fù)制 ：在
Master端開啟binlog柄延，然后將binlog發(fā)送到各個Slave端，Slave端重放binlog從而達(dá)到主從數(shù)據(jù)一致缀程。數(shù)據(jù)恢復(fù) ：通過使用
mysqlbinlog工具來恢復(fù)數(shù)據(jù)搜吧。
binlog刷盤時機(jī)
對于 InnoDB 存儲引擎而言，只有在事務(wù)提交時才會記錄 biglog 杨凑，此時記錄還在內(nèi)存中滤奈，那么 biglog
是什么時候刷到磁盤中的呢？mysql 通過 sync_binlog 參數(shù)控制 biglog 的刷盤時機(jī)撩满，取值范圍是 0-N
：
0：不去強(qiáng)制要求蜒程，由系統(tǒng)自行判斷何時寫入磁盤；
1：每次
commit的時候都要將binlog寫入磁盤伺帘；N：每N個事務(wù)昭躺，才會將
binlog寫入磁盤。
從上面可以看出伪嫁， sync_binlog 最安全的是設(shè)置是 1 窍仰，這也是 MySQL 5.7.7
之后版本的默認(rèn)值。但是設(shè)置一個大一些的值可以提升數(shù)據(jù)庫性能礼殊，因此實(shí)際情況下也可以將值適當(dāng)調(diào)大驹吮，犧牲一定的一致性來獲取更好的性能针史。
binlog日志格式
binlog 日志有三種格式，分別為 STATMENT 碟狞、 ROW 和 MIXED 啄枕。
在
MySQL 5.7.7之前，默認(rèn)的格式是STATEMENT族沃，MySQL 5.7.7之后频祝，默認(rèn)值是ROW。日志格式通過binlog-format指定脆淹。
STATMENT：基于SQL語句的復(fù)制(statement-based replication, SBR)常空，每一條會修改數(shù)據(jù)的sql語句會記錄到binlog中 。優(yōu)點(diǎn)：不需要記錄每一行的變化盖溺，減少了 binlog 日志量漓糙，節(jié)約了 IO , 從而提高了性能；
缺點(diǎn)：在某些情況下會導(dǎo)致主從數(shù)據(jù)不一致烘嘱，比如執(zhí)行sysdate() 昆禽、 slepp() 等 。
ROW：基于行的復(fù)制(row-based replication, RBR)蝇庭，不記錄每條sql語句的上下文信息醉鳖，僅需記錄哪條數(shù)據(jù)被修改了 。優(yōu)點(diǎn)：不會出現(xiàn)某些特定情況下的存儲過程哮内、或function盗棵、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題 ；
缺點(diǎn)：會產(chǎn)生大量的日志北发，尤其是
alter table的時候會讓日志暴漲MIXED：基于STATMENT和ROW兩種模式的混合復(fù)制(mixed-based replication, MBR)纹因，一般的復(fù)制使用STATEMENT模式保存binlog，對于STATEMENT模式無法復(fù)制的操作使用ROW模式保存binlog
redo log
為什么需要redo log
我們都知道鲫竞，事務(wù)的四大特性里面有一個是 持久性 辐怕，具體來說就是
只要事務(wù)提交成功，那么對數(shù)據(jù)庫做的修改就被永久保存下來了从绘，不可能因?yàn)槿魏卧蛟倩氐皆瓉淼臓顟B(tài) 寄疏。那么 mysql
是如何保證一致性的呢？最簡單的做法是在每次事務(wù)提交的時候僵井，將該事務(wù)涉及修改的數(shù)據(jù)頁全部刷新到磁盤中陕截。但是這么做會有嚴(yán)重的性能問題，主要體現(xiàn)在兩個方面：
因?yàn)?
Innodb是以頁為單位進(jìn)行磁盤交互的批什，而一個事務(wù)很可能只修改一個數(shù)據(jù)頁里面的幾個字節(jié)农曲，這個時候?qū)⑼暾臄?shù)據(jù)頁刷到磁盤的話，太浪費(fèi)資源了！一個事務(wù)可能涉及修改多個數(shù)據(jù)頁乳规，并且這些數(shù)據(jù)頁在物理上并不連續(xù)形葬，使用隨機(jī)IO寫入性能太差！
因此 mysql 設(shè)計(jì)了 redo log 暮的， 具體來說就是只記錄事務(wù)對數(shù)據(jù)頁做了哪些修改
笙以，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。
redo log基本概念
redo log 包括兩部分：一個是內(nèi)存中的日志緩沖( redo log buffer )冻辩，另一個是磁盤上的日志文件( redo log file )猖腕。mysql 每執(zhí)行一條 DML 語句，先將記錄寫入 redo log buffer
恨闪，后續(xù)某個時間點(diǎn)再一次性將多個操作記錄寫到 redo log file 倘感。這種 先寫日志，再寫磁盤 的技術(shù)就是 MySQL
里經(jīng)常說到的 WAL(Write-Ahead Logging) 技術(shù)咙咽。
在計(jì)算機(jī)操作系統(tǒng)中老玛，用戶空間( user space )下的緩沖區(qū)數(shù)據(jù)一般情況下是無法直接寫入磁盤的，中間必須經(jīng)過操作系統(tǒng)內(nèi)核空間( kernel space )緩沖區(qū)( OS Buffer )犁珠。因此逻炊， redo log buffer 寫入 redo log file 實(shí)際上是先寫入 OS Buffer 互亮，然后再通過系統(tǒng)調(diào)用 fsync() 將其刷到 redo log file
中犁享，過程如下：
mysql 支持三種將 redo log buffer 寫入 redo log file 的時機(jī)，可以通過 innodb_flush_log_at_trx_commit 參數(shù)配置豹休，各參數(shù)值含義如下：
| 參數(shù)值 | 含義 |
|---|---|
| 0（延遲寫） | 事務(wù)提交時不會將 redo log buffer 中日志寫入到 os buffer 炊昆，而是每秒寫入 os buffer 并調(diào)用 fsync() 寫入到 redo log file 中。也就是說設(shè)置為0時是(大約)每秒刷新寫入到磁盤中的威根，當(dāng)系統(tǒng)崩潰凤巨，會丟失1秒鐘的數(shù)據(jù)。 |
| 1（實(shí)時寫洛搀，實(shí)時刷） | 事務(wù)每次提交都會將 redo log buffer 中的日志寫入 os buffer 并調(diào)用 fsync() 刷到 redo log file 中敢茁。這種方式即使系統(tǒng)崩潰也不會丟失任何數(shù)據(jù)，但是因?yàn)槊看翁峤欢紝懭氪疟P留美，IO的性能較差彰檬。 |
| 2（實(shí)時寫，延遲刷） | 每次提交都僅寫入到 os buffer 谎砾，然后是每秒調(diào)用 fsync() 將 os buffer中的日志寫入到 redo log file 逢倍。 |
redo log記錄形式
前面說過， redo log 實(shí)際上記錄數(shù)據(jù)頁的變更景图，而這種變更記錄是沒必要全部保存较雕，因此 redo log
實(shí)現(xiàn)上采用了大小固定，循環(huán)寫入的方式挚币，當(dāng)寫到結(jié)尾時亮蒋，會回到開頭循環(huán)寫日志扣典。如下圖：
同時我們很容易得知， 在innodb中慎玖，既有redo log 需要刷盤激捏，還有 數(shù)據(jù)頁 也需要刷盤， redo log存在的意義主要就是降低對 數(shù)據(jù)頁 刷盤的要求 ** 凄吏。在上圖中远舅， write pos 表示 redo log 當(dāng)前記錄的 LSN (邏輯序列號)位置， check point 表示 數(shù)據(jù)頁更改記錄 刷盤后對應(yīng) redo log 所處的 LSN(邏輯序列號)位置痕钢。write pos 到 check point 之間的部分是 redo log 空著的部分图柏，用于記錄新的記錄；check point 到 write pos 之間是 redo log 待落盤的數(shù)據(jù)頁更改記錄任连。當(dāng) write pos追上 check point時蚤吹，會先推動 check point 向前移動，空出位置再記錄新的日志随抠。
啟動 innodb 的時候墨辛，不管上次是正常關(guān)閉還是異常關(guān)閉，總是會進(jìn)行恢復(fù)操作第练。因?yàn)?redo log記錄的是數(shù)據(jù)頁的物理變化瑞妇，因此恢復(fù)的時候速度比邏輯日志(如 binlog )要快很多。重啟 innodb 時秉沼，首先會檢查磁盤中數(shù)據(jù)頁的 LSN 桶雀，如果數(shù)據(jù)頁的 LSN 小于日志中的 LSN ，則會從 checkpoint 開始恢復(fù)唬复。還有一種情況矗积，在宕機(jī)前正處于
checkpoint 的刷盤過程，且數(shù)據(jù)頁的刷盤進(jìn)度超過了日志頁的刷盤進(jìn)度敞咧，此時會出現(xiàn)數(shù)據(jù)頁中記錄的 LSN 大于日志中的 LSN
棘捣，這時超出日志進(jìn)度的部分將不會重做，因?yàn)檫@本身就表示已經(jīng)做過的事情休建，無需再重做乍恐。
redo log與binlog區(qū)別
|
| redo log | binlog |
| --- | --- | --- |
| 文件大小 | redo log 的大小是固定的。 | binlog 可通過配置參數(shù) max_binlog_size 設(shè)置每個binlog 文件的大小丰包。 |
| 實(shí)現(xiàn)方式 | redo log 是 InnoDB 引擎層實(shí)現(xiàn)的禁熏，并不是所有引擎都有。 | binlog 是 Server 層實(shí)現(xiàn)的邑彪，所有引擎都可以使用 binlog 日志 |
| 記錄方式 | redo log 采用循環(huán)寫的方式記錄瞧毙，當(dāng)寫到結(jié)尾時，會回到開頭循環(huán)寫日志。 | binlog通過追加的方式記錄宙彪，當(dāng)文件大小大于給定值后矩动，后續(xù)的日志會記錄到新的文件上 |
| 適用場景 | redo log 適用于崩潰恢復(fù)(crash-safe) | binlog 適用于主從復(fù)制和數(shù)據(jù)恢復(fù) |
由 binlog 和 redo log 的區(qū)別可知：binlog 日志只用于歸檔，只依靠 binlog 是沒有 crash-safe 能力的释漆。但只有 redo log 也不行悲没，因?yàn)?redo log 是 InnoDB
特有的，且日志上的記錄落盤后會被覆蓋掉男图。因此需要 binlog 和 redo log
二者同時記錄示姿，才能保證當(dāng)數(shù)據(jù)庫發(fā)生宕機(jī)重啟時，數(shù)據(jù)不會丟失逊笆。
undo log
數(shù)據(jù)庫事務(wù)四大特性中有一個是 原子性 栈戳，具體來說就是 原子性是指對數(shù)據(jù)庫的一系列操作，要么全部成功难裆，要么全部失敗子檀，不可能出現(xiàn)部分成功的情況
。實(shí)際上乃戈， 原子性 底層就是通過 undo log 實(shí)現(xiàn)的褂痰。undo log 主要記錄了數(shù)據(jù)的邏輯變化，比如一條 INSERT 語句症虑，對應(yīng)一條 DELETE 的 undo log 缩歪，對于每個 UPDATE 語句，對應(yīng)一條相反的 UPDATE 的 undo log 侦讨，這樣在發(fā)生錯誤時驶冒，就能回滾到事務(wù)之前的數(shù)據(jù)狀態(tài)苟翻。同時韵卤， undo log 也是 MVCC(多版本并發(fā)控制)實(shí)現(xiàn)的關(guān)鍵，這部分內(nèi)容在 面試中的老大難-mysql事務(wù)和鎖崇猫，一次性講清楚沈条！中有介紹，不再贅述诅炉。
