1. 事務日誌可以幫助提高事務的效率。使用事務日誌，存儲引擎在修改表的數據時只需要修改其內存拷貝，再把該修改行爲記錄到持久在硬盤上的事務日誌中，而不用每次都將修改的數據本身持久到磁盤。事務日誌採用的是追加的方式，因此寫日誌的操作是磁盤上一小塊區域內的順序I/O，而不像隨機I/O需要在磁盤的多個地方移動磁頭，所以採用事務日誌的方式相對來說要快得多。事務日誌持久以後，內存中被修改的數據在後臺可以慢慢地刷回到磁盤，通常稱之爲預寫式日誌（Write-Ahead Logging），修改數據需要寫兩次磁盤。
MySQL Innodb中跟數據持久性、一致性有關的日誌，有以下幾種：
- Bin Log:是mysql服務層產生的日誌，常用來進行數據恢復、數據庫複製，常見的mysql主從架構，就是採用slave同步master的binlog實現的
- Redo Log:記錄了數據操作在物理層面的修改，mysql中使用了大量緩存，修改操作時會直接修改內存，而不是立刻修改磁盤，事務進行中時會不斷的產生redo log，在事務提交時進行一次flush操作，保存到磁盤中。當數據庫或主機失效重啓時，會根據redo log進行數據的恢復，如果redo log中有事務提交，則進行事務提交修改數據。
- Undo Log: 除了記錄redo log外，當進行數據修改時還會記錄undo log，undo log用於數據的撤回操作，它記錄了修改的反向操作，比如，插入對應刪除，修改對應修改爲原來的數據，通過undo log可以實現事務回滾，並且可以根據undo log回溯到某個特定的版本的數據，實現MVCC
2. InnoDB的MVCC（Multi-Version Concurrency Control，多版本併發控制），是爲了查詢一些正在被另一個事務更新的行，並且可以看到它們被更新之前的值。這是一個可以用來增強併發性的強大的技術，因爲查詢不用等待另一個事務釋放鎖。
實現原理：在每一行記錄的後面增加兩個隱藏列，記錄創建版本號和刪除版本號，每開啓一個新事務，事務的版本號就會遞增，並把查詢到的數據複製到內存中，後續的所有增刪改查操作都是針對於內存中的數據，再把修改行爲記錄到持久在硬盤上的事務日誌中(redo log)，而不用每次都將修改的數據本身持久到磁盤。在事務提交時進行一次flush操作，根據redo log保存到磁盤中。
MVCC解決了RR級別的幻讀和高併發下的讀操作（快照讀）。
快照讀：讀取的是快照版本（內存數據），普通的SELECT就是快照讀，而UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE是當前讀。
鎖定讀：SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE讀的是磁盤真正數據，並且加了共享鎖，其它事務只能讀不能修改，直到當前事務提交，跟UPDATE的加鎖情況是一樣的，即只允許當前事務進行讀寫，其他事務只能讀，不能增刪改。