MySQL事務提交流程時序圖
網上的資料有點亂，所以特畫此圖，從上帝視角，來看事務操作的主要流程，此圖爲事務處理的簡化時序圖，在處理細節上省略了和多線程複製相關的操作，innodb各個階段的詳細操作，重在說明流程。
一、簡化版的事務處理時序圖
時序圖說明
關於此圖的必要性說明
- 如果你想了解group commit的詳細機制，此圖不適合，因爲此圖忽略了組提交的細節。
- 如果你想了解Innodb落盤機制，此圖不適合，因爲也忽略了。
- 此圖基於Oracle MySQL-5.7.18 社區版
- 省略了server通過handler操作storage在整個事務處理過程中的關係
- 省略了innobase的各個階段的詳細操作
- TC_LOG在MySQL開啓binlog時，其實就是MYSQL_BIN_LOG，MYSQL_BIN_LOG同時作爲事務協調者和事務參與者，所以圖中存在TC這個層級，所有TC的處理其實是MYSQL_BIN_LOG的處理，TC封裝了接口供上層調用。
- 資源管理器並不是向TC註冊,但是此圖省略了這部分內容，顯示爲向TC註冊。因爲最終在事務提交操作時，TC會遍歷資源管理器來進行操作。
- 此圖在缺少本說明的情況下，不要隨意複製粘貼，以免引起讀者的誤會。
- 此圖源自於源碼，但是不涉及源碼。
- 能力有限，對於代碼的理解也有限，畫圖水平更有限，有錯誤請指正。
時序圖如下：
二、流程簡介
如下是對時序圖的簡要說明，不會涉及太多細節，可以說基本沒有涉及細節部分。
用戶下發begin操作
如果在begin操作前，存在顯示開啓的未提交的事務，則begin操作會觸發之前事務的提交，對這種情況不進行說明。
客戶端下發begin操作時，server會去檢測事務開啓的參數，可以見help。begin在存儲引擎不會做任何實質性的操作，但是MySQL處理完begin後，也會去調用tc commit操作，調用檢測用戶無任何寫入操作既返回。（忽略部分細節，詳細可看代碼）
用戶進行dml操作
用戶下發dml數據寫入操作，此時資源管理器進行註冊，並且開始工作，比如innobase註冊後處理真正的undo，redo，數據頁變更操作。MYSQL_BIN_LOG註冊後處理記錄二進制日誌。
隨後是prepare動作，由於是非commit，非自動提交，所以此時binlog的prepare是獲取當前最大事務提交數量（和多線程複製相關），不做真正的binlog落盤操作，innobase的prepare記錄事務回滾點位，其實就是下一條sql如果失敗了需要根據undo進行回滾，但是要知道回滾到什麼位置，，不做redo的刷盤操作。
用戶下發commit
客戶端下發commit命令，此時進入真正的兩階段提交，兩階段提交分爲prepare和commit兩個階段
-
prepare
prepare分爲binlog prepare和innobase prepare,其中binlog prepare幾乎不做操作，innobase prepare會更新事務狀態。 -
commit
commit階段被分爲了三個階段，分別是flush，sync，commit。其中 flush操作會進行線程binlog cache的文件寫入，再將用戶binlog cache刷新到文件；sync操作負責binlog的落盤；commit操作負責更新server層的最大事務提交數量(和並行複製相關),然後innobase 再次更新事務狀態。提交結束。
源碼分析的話可能要寫的很久很長，另外一篇再介紹吧。