https://www.cnblogs.com/better-farther-world2099/p/9290966.html
undolog實現事務原子性，redolog實現事務的持久性。
為了避免臟數據刷回磁盤過程中，掉電或系統故障帶來的數據丟失問題，InnoDB采用事務日志（redo log）來解決該問題。
數據庫數據存放的文件稱為data file；
日志文件稱為log file；
數據庫數據是有緩存的，如果沒有緩存，每次都寫或者讀物理disk，那性能就太低下了。數據庫數據的緩存稱為data buffer，日志（redo）緩存稱為log buffer。
內存緩沖池
buffer pool如果mysql不用內存緩沖池，每次讀寫數據時，都需要訪問磁盤，必定會大大增加I/O請求，導致效率低下。所以Innodb引擎在讀寫數據時，把相應的數據和索引載入到內存中的緩沖池(buffer pool)中，一定程度的提高了數據讀寫的速度。
buffer pool：占最大塊內存，用來存放各種數據的緩存包括有索引頁、數據頁、undo頁、插入緩沖、自適應哈希索引、innodb存儲的鎖信息、數據字典信息等。工作方式總是將數據庫文件按頁(每頁16k)讀取到緩沖池，然后按最近最少使用(lru)的算法來保留在緩沖池中的緩存數據。如果數據庫文件需要修改，總是首先修改在緩存池中的頁(發生修改后即為臟頁dirty page)，然后再按照一定的頻率將緩沖池的臟頁刷新到文件。
redo log 和undo log
為了滿足事務的持久性，防止buffer pool數據丟失，innodb引入了redo log。為了滿足事務的原子性，innodb引入了undo log。
delete/update操作的內部機制
當事務提交的時候，innodb不會立即刪除undo log，因為后續還可能會用到undo log，如隔離級別為repeatable read時，事務讀取的都是開啟事務時的最新提交行版本，只要該事務不結束，該行版本就不能刪除，即undo log不能刪除。
但是在事務提交的時候，會將該事務對應的undo log放入到刪除列表中，未來通過purge來刪除。並且提交事務時，還會判斷undo log分配的頁是否可以重用，如果可以重用，則會分配給后面來的事務，避免為每個獨立的事務分配獨立的undo log頁而浪費存儲空間和性能。
Undo Log的原理很簡單，為了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱為Undo Log）。然后進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態。
引入buffer pool會導致更新的數據不會實時持久化到磁盤，當系統崩潰時，雖然buffer pool中的數據丟失，數據沒有持久化，但是系統可以根據Redo Log的內容，將所有數據恢復到最新的狀態。redo log在磁盤上作為一個獨立的文件存在。默認情況下會有兩個文件，名稱分別為 ib_logfile0和ib_logfile1。
redo log的記錄內容
undo log和 redo log本身是分開的。innodb的undo log是記錄在數據文件(ibd)中的，而且innodb將undo log的內容看作是數據，因此對undo log本身的操作(如向undo log中插入一條undo記錄等)，都會記錄redo log。undo log可以不必立即持久化到磁盤上。即便丟失了，也可以通過redo log將其恢復。因此當插入一條記錄時：
- 向undo log中插入一條undo log記錄。
- 向redo log中插入一條”插入undo log記錄“的redo log記錄。
- 插入數據。
- 向redo log中插入一條”insert”的redo log記錄。
redo log的io性能
為了保證Redo Log能夠有比較好的IO性能，InnoDB 的 Redo Log的設計有以下幾個特點：
- 盡量保持Redo Log存儲在一段連續的空間上。因此在系統第一次啟動時就會將日志文件的空間完全分配。以順序追加的方式記錄Redo Log。
- 批量寫入日志。日志並不是直接寫入文件，而是先寫入redo log buffer,然后每秒鍾將buffer中數據一並寫入磁盤
- 並發的事務共享Redo Log的存儲空間，它們的Redo Log按語句的執行順序，依次交替的記錄在一起，以減少日志占用的空間。
- Redo Log上只進行順序追加的操作，當一個事務需要回滾時，它的Redo Log記錄也不會從Redo Log中刪除掉。