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的線上工具，發現百度腦圖還可以，關鍵是線上的，隨時隨地就都可以開啟整理相關的知識點。