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)，它對於接下來操作的時序安排是至關重要的。
下面是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只需要比較這個數字就可以進行同步
