MySQL InnoDB 事務實現過程相關內容的概述

MySQL事務的實現涉及到redo和undo以及purge，redo是保證事務的原子性和持久性；undo是保證事務的一致性（一致性讀和多版本併發控制）；purge清理undo表空間
背景知識，對於Innodb表中的行每一行包括：
6字節的事務ID(DB_TRX_ID)字段: 用來標識最近一次對本行記錄作修改(INSERT|UPDATE)的事務的標識符, 即最後一次修改(INSERT|UPDATE)本行記錄的事務id。
7字節的回滾指針(DB_ROLL_PTR)字段: 指寫入回滾段(ROLLBACK segment)的 UNDO LOG record (撤銷日誌記錄記錄)。
若是一行記錄被更新, 則 UNDO LOG record 包含 '重建該行記錄被更新以前內容' 所必須的信息。

 

1，MySQL事務執行過程當中，
　　對於undo log
　　　　對於update或者delete操做，每一行都保存了一個事務Id，修改事務Id爲當前Session的事務id，
　　　　生成數據行事務以前的版本，將當前行的回滾指針指向事務以前的版本。
　　　　對於insert操做，將當前行的回滾指針指爲空，由於insert沒有事務操做以前的版本。
　　對於redo log
　　　　隨着update\delete\insert操做的執行，重作日誌Redo Log不斷地寫入重作日誌緩存（redo_log_buffer）,
　　　　對於Redo Log Buffer的落盤（寫入 Redo Log File），有三種策略：
　　　　(1)，事務commit的時候，
　　　　(2)，redo_log_buffer（默認8MB）使用超過50%的時候，
　　　　(3)，發生checkpoint的時候
　　　　也就是說，Redo Log Buffe的落盤並不必定是事務提交的時候才寫入的，對於大事務，redo log是有可能逐步落盤的（2,3兩點的影響）

2，事務的提交Commit
　　Redo Log Buffer的寫盤，由變量innodb_flush_log_at_trx_commit決定，有三種模式分別是0,1,2
　　若是設置爲0，事物提交不觸發Redo Log Buffer寫盤，每N秒將Redo Log Buffer的記錄寫入Redo Log文件，而且將Redo Log文件刷入硬件存儲1次，N由innodb_flush_log_at_timeout控制。
　　若是設置爲1，事務提交時同步刷新Redo Log Buffe到Redo Log文件，而且將Redo Log文件刷新到磁盤。
　　若是設置爲2，事務提交時同步刷新Redo Log Buffe到Redo Log文件，.可是Redo Log 的flush(刷到磁盤)操做並不會同時進行。Redo Log的寫盤由操做系統和innodb_flush_log_at_timeout控制。
　　須要注意的是，innodb_flush_log_at_trx_commit=1的狀況下，儘管事務提交能夠保證redo log同步寫盤，
　　可是Redo Log Buffer的寫盤並不必定只有在事務提交的時候才寫入的，有多是隨着時候的執行（若是事務很大）逐步寫盤的。

3，事務提以後
　　由於redo log的存在（寫盤以後），事務的一致性和持久性獲得了保證，對於內存中的髒數據，經過checkpoint或者內存機制刷入磁盤，在數據寫入磁盤以後，redo log空間便可釋放
　　對於undo log，當沒有活動Session訪問的時候，由purge線程異步清理undo log佔用的空間

 

見很多人寫博客使用xmind或者其餘工具對相關知識點進行整理，
發現相似於xmind的結構圖對於知識結構很是清晰，xmind第一份工做用過，很久沒用了，裝了試用版發現功能受限不少。
因而嘗試相似於xmind的在線工具，發現百度腦圖還能夠，關鍵是在線的，隨時隨地就均可以打開整理相關的知識點。

 

參考：
https://segmentfault.com/a/1190000012650596
https://liuzhengyang.github.io/2017/04/18/innodb-mvcc/
MySQL技術內幕 InnoDB存儲引擎