MySQL事務提交流程概述

儲存引擎實現事務的通用方式是基於 redo log 和 undo log。


簡單來說，redo log 記錄事務修改後的資料, undo log 記錄事務前的原始資料。


所以當一個事務執行時實際發生過程簡化描述如下：


先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
更新資料記錄，快取操作並非同步刷盤。
提交事務，在 redo log 中寫入 commit 記錄。
在 MySQL 執行事務過程中如果因故障中斷，可以透過 redo log 來重做事務或透過 undo log 來回滾，確保了資料的一致性。


這些都是由事務性儲存引擎來完成的，但 binlog 不在事務儲存引擎範圍內，而是由 MySQL Server 來記錄的。


那麼就必須保證 binlog 資料和 redo log 之間的一致性，所以開啟了 binlog 後實際的事務執行就多了一步，如下：


先記錄 undo/redo log，確保日誌刷到磁碟上持久儲存。
更新資料記錄，快取操作並非同步刷盤。
將事務日誌持久化到 binlog。
提交事務，在 redo log 中寫入commit記錄。
這樣的話，只要 binlog 沒寫成功，整個事務是需要回滾的，而 binlog 寫成功後即使 MySQL Crash 了都可以恢復事務並完成提交。

 
MySQL是透過WAL方式，來保證資料庫事務的一致性和永續性，即ACID特性中的C(consistent)和D(durability)。
WAL（Write-Ahead Logging）是一種實現事務日誌的標準方法，具體而言就是:

1、修改記錄前，一定要先寫日誌；

2、事務提交過程中，一定要保證日誌先落盤，才能算事務提交完成。

透過WAL方式，在保證事務特性的情況下，可以提高資料庫的效能。

從上述流程可以看出，提交過程中，主要做了4件事情，

1、清理undo段資訊，對於innodb儲存引擎的更新操作來說，undo段需要purge，這裡的purge主要職能是，真正刪除物理記錄。在執行delete或update操作時，實際舊記錄沒有真正刪除，只是在記錄上打了一個標記，而是在事務提交後，purge執行緒真正刪除，釋放物理頁空間。因此，提交過程中會將undo資訊加入purge列表，供purge執行緒處理。


2、釋放鎖資源，mysql透過鎖互斥機制保證不同事務不同時操作一條記錄，事務執行後才會真正釋放所有鎖資源，並喚醒等待其鎖資源的其他事務；


3、刷redo日誌，前面我們說到，mysql實現事務一致性和永續性的機制。透過redo日誌落盤操作，保證了即使修改的資料頁沒有即使更新到磁碟，只要日誌是完成了，就能保證資料庫的完整性和一致性；


4、清理儲存點列表，每個語句實際都會有一個savepoint(儲存點)，儲存點作用是為了可以回滾到事務的任何一個語句執行前的狀態，由於事務都已經提交了，所以儲存點列表可以被清理了。