MySQL事務提交的流程

本篇內容介紹了“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(保存點)，保存點作用是為了可以回滾到事務的任何一個語句執行前的狀態，由于事務都已經提交了，所以保存點列表可以被清理了。

“MySQL事務提交的流程”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！