資料儲存 MySQL之InnoDB實現事務

redo log是物理格式上的innodb日誌，記錄儲存引擎為innodb的資料庫中每個頁的修改。

redo log包括兩個部分：

1.記憶體中的日誌緩衝(redo log buffer)，因為處於記憶體中，所以這部分日誌內容是容易丟失的。

2.磁碟上的重做日誌檔案(redo log file)，這部分日誌是持久的。

innodb通過force log at commit機制實現事務的永續性。

mysql支援使用者自定義在提交事務時如何將log buffer中的日誌刷到log file中。這種控制通過innodb_flush_log_at_trx_commit的值來決定。該變數有3種值：0、1、2，預設為1。

undo log有兩個作用：提供回滾和多個行版本控制（mvcc）。

在資料修改的時候，不僅記錄了redo，還記錄了相對應的undo，如果因為某些原因導致事務提交失敗，可以借助undo log回滾。

undo log和redo log記錄物理日誌不一樣，他是邏輯日誌。可以認為當delete一條記錄時，undo log中會記錄一條對應insert語句，當update一條記錄的時候，會記錄一條相反的update記錄。

當執行rollback時，就可以從undo log中的邏輯記錄讀取到相應的內容並進行回滾。有時候應用到mvcc時，也是通過undo log來實現的：當讀取的某一行被其他事務鎖定時，它可以從undo log中分析出該行記錄以前的資料是什麼，從而提供該行版本資訊，讓使用者實現非鎖定一致性讀取。

undo log是採用段(segment)的方式來記錄的，每個undo操作在記錄的時候占用乙個undo log segment。

另外，undo log也會產生redo log，因為undo log也要實現永續性保護。

1.當事務提交時，必須先將該事務的所有日誌寫入到日誌檔案進行持久化，之後完成commit。

2.日誌寫入日誌檔案時，日誌緩衝先寫入檔案系統快取，為了確保寫入磁碟，需要呼叫一次fsync操作。

3.由於fsync的效率取決於磁碟的效能，因此磁碟的效能決定了事務提交的效能，也就是資料庫的效能。fsync會同步記憶體中所有已修改的檔案資料到磁碟。