如何解讀MySQL的InnoDB引擎日志工作原理

這篇文章主要介紹了如何解讀MySQL的InnoDB引擎日志工作原理，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

當你使用UPDATE, INSERT, DELETE語句更新數據的時候，你就改變了兩個地方的數據：log buffer和data buffers。Buffers是固定長度的內存塊，通常是512字節。

LOG BUFFER           DATA BUFFER
=================    ===============
= Log Record #1 =    = Page Header =
= Log Record #2 =    = Data Row    =
= Log Record #3 =    = Data Row    =
= Log Record #4 =    = Data Row    =
=================    ===============例如：INSERT INTO JOBS VALUES(1,2,3)語句執行之后，log buffer將增加一個新的log記錄，稱為Log Record #5，它包含一個rowid和新記錄的內容。同時，data buffer也將增加一個新行，但是，它會同時在頁頭標識：該頁最新的log記錄是Log Record #5。在這個例子中#5是Log Sequence Number（LSN），它對于接下來操作的時序安排是至關重要的。

[@more@]

下面是data-change的一些細節：

1.         一個INSERT log記錄僅包含一個新數據，它對于在頁上重做操作是足夠的了，因此被稱為一個redo條目。

2.         LSN不是log記錄的一個域，它是文件中的一個絕對地址的相對偏移值。

在InnoDB改變了log buffer和data buffer之后，接下來就是寫盤了。這就是復雜的地方。有多個線程在監控buffer的活動情況，有三種情況――overflow， checkpoint和commit――可以導致寫盤操作。

Overflows情況下發生了什么？

Overflow是很少發生的情況，因為InnoDB采用pro-active措施來防止buffers被填滿。但是我們還是來看看下面兩種情況：

1.         如果log buffer滿了，InnoDBInnoDB在buffer的末尾寫log。那么情況向下面的圖一樣（log buffer只有四條記錄的空間，現在插入第五條記錄）：

LOG FILE(S) BEFORE WRITING LOG RECORD #5
=================
= Log Record #1 =
= Log Record #2 =
= Log Record #3 =
= Log Record #4 =
=================

LOG FILE(S) AFTER WRITING LOG RECORD #5
=================
= Log Record #5 =
= Log Record #2 =
= Log Record #3 =
= Log Record #4 =
=================logs不可能永遠增長。即使InnoDB使用了某些壓縮算法，log文件還是會由于太大而不能放到任何磁盤驅動器上。因此InnoDB采取循環寫的辦法，也就是說將會覆蓋前面就的log記錄。

2.         如果data buffer滿了，InnoDB將最近使用的buffer寫入到數據庫中，但是不可能足夠的快。這種情況下，頁頭的LSN就起作用了。第一，InnoDB檢查它的LSN是否比log文件中最近的log記錄的LSN大，只有當log趕上了data的時候，才會將數據寫到磁盤。換句話說，數據頁不會寫盤，直到相應的log記錄需要寫盤的時候。這就是先寫日志策略。

CheckPoints的時候發生了什么？

前面說過InnoDB采取了一些pro-active措施來保證不發生overflows，其中最重要的措施就是checkpointing。有一個分離的線程，或者說從一組修改buffers的線程中分離出來的一個線程。在特定的時間間隔，checkpointer將醒來，檢查buffer的改變，并保證寫盤操作已經發生了。

大部分DBMS在這個時候，將會把所有的buffer寫盤，這樣可以保證所有改變了但是沒寫盤的buffer都寫盤。就是說DBMS將通過”Sharp Checkpoint” flush所有”dirty”buffers。但是InnoDB只保證：（a）log和data buffers不會超過某個限制點；（b）log始終比data先寫盤；（c）沒有哪個data buffer的頁頭LSN等于被覆蓋寫的log記錄。也就是說InnoDB是”Fuzzy Checkpoint”。

在COMMIT的時候，InnoDB不會將dirty data page寫盤。之所以強調這個是因為，很容易讓人想到，提交改變就是將所有東西寫到一個持久媒介上。其實，只有log記錄需要寫。寫dirty data page只可能發生在overflow或checkpoint時刻，因為它們的內容是多余的。

Recovery

在recovery里面可以看到log是非常必要的：當數據庫發生異常的時候，數據是可以恢復的。

對于不是損壞磁盤驅動器的異常，恢復是自動進行的。InnoDB讀取最新的checkpoint日志記錄，檢查dirty pages是否在異常發生前寫到磁盤上了，如果沒有，則讀取影響該頁的log記錄并應用它們。這被稱為”rolling forward”。因為有LSN，所以InnoDB只需要比較這個數字就可以進行同步。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“如何解讀MySQL的InnoDB引擎日志工作原理”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!