mysql-innodb-事務

1. 事務概述

• 事務執行中要麼都修改，要麼都不修改，這是事務模型與文件系統重要區別之一。

• innodb引擎都事務徹底符合ACID特徵：

  1. 原子性（Atomicity，或稱不可分割性）

     • 事務中的全部操做均爲一個總體，要麼所有成功，要麼有一條執行失敗後回滾到事務前的狀態。經過redo log實現。

  2. 一致性（Consistency）

     • 事務是一致性的單位，若是事務中某個動做失敗了，系統能夠撤銷事務，返回初始狀態。經過undo log實現。
     • 例如表中name字段是惟一約束，事務提交後或發生回滾後，name變得不惟一了，這就是破壞了一致性要求。

  3. 隔離性（Isolation）

     • 隔離性要求每一個讀寫事務的對象對其餘事務對操做對象都是相互分離的，一般用鎖來實現。
     • 經過各類鎖來配合實現不一樣級別都隔離性。例如行鎖，間隙鎖等。

  4. 持久性（Durability）

     • 事務一旦commit成功，結果就是永久性的。即便發生宕機也能將數據恢復。但外部緣由除外。是經過redo log來實現的。

2. 事務分類

扁平事務

• 全部事務處於同一層次。其操做都是原子性，要不所有成功，要不所有失敗。

帶有保存點的扁平事務

• 除了支持扁平事務支持的操做外，爲事務幾個過程設置保存點，容許回滾到事務中較早的某個節點。
• 對於扁平事務來講，其隱式設置了一個起始保存點。所以只能回滾到事務開始時的狀態。
• 保存點用SAVE WORK函數創建，保存點在事務內部是遞增的，根據應用邏輯選擇回到哪一個保存點。

鏈事務

• 保存點是非持久化都，當系統崩潰時，全部保存點都將消失，當進行恢復時，事務須要從新開始執行。
• 鏈事務思想：T1事務提交時，把必要處理都上下文隱式傳給T2事務，以此類推。這意味着下一個事務能看到上一個事務的執行結果。
• 鏈事務只能保證回滾到最近的一個保存點。

嵌套事務

• 由若干事務組成一顆事務樹，子樹能夠是嵌套事務也能夠是扁平事務。
• 處於根節點的是頂層事務， 一個頂層事務控制着各個層次的子事務。
• 處在葉子節點的是扁平事務，每一個子事務的從根到葉子節點的距離能夠不一樣。
• 子事務能夠commit或rollback，可是commit並不是當即生效，除非父事務已經commit，故任何子事務都在頂層事務提交完畢後才真正提交。
• 樹的任意一個事務回滾會致使它全部的子事務一塊兒回滾。故子事務僅保留ACI特性，不具有D特性。
• 在Moss理論中，只有葉子節點的事務才能完成訪問數據庫，發送消息等操做。高層事務僅負責邏輯調度控制，決定什麼時候調用相關等子業務。

分佈式事務

• 一般是在一個分佈式環境下運行的扁平事務。

3. 事務實現

概述：事務的隔離行是由鎖來實現的。原子性，一致性和持久性是經過redo log和undo log實現的。redo log稱爲重作日誌。用來保證事務的原子性和持久性。undo log用來保證事務的一致性。redo是物理日誌，記錄的是頁的物理修改。undo是邏輯日誌，根據每行記錄進行記錄，能夠回滾行記錄到某個版本。

3.1 redo

1. 概述

   • 重作日誌用來實現事務的持久性，由兩部分組成，一個是內存中的重作日誌緩衝（redo log buffer），另外一個是重作日誌文件（redo log file）這是持久性的。redo log基本上都是順序寫的，數據庫運行時不須要進行讀取操做。

2. 與binlog比較

   1. 產生層面

      • binlog產生於mysql數據庫上層，不針對innodb引擎。
      • redolog產生於innodb引擎層，是innodb特有的日誌。

   2. 內容形式

      • binlog是一種邏輯日誌，記錄的的是對應的sql語句。
      • redolog是物理格式的日誌，記錄的是對每一個頁的修改。

   3. sync時間點

      • binlog只在事務commit完成後寫入一次。
      • redolog在事務進行中不斷被寫入。

3. log block

   • 概述：innodb中，redolog都是以512字節進行存儲的。這意味着redo log buffer和redo log file都是以塊(block)進行存儲的。因爲重作日誌塊大小和磁盤山區都是512字節，因此寫入都是原子性的，不須要double write技術。

4. LSN

   1. 概述：LSN（Log Sequence Number）表明的是日誌序列號。在innodb引擎中LSN佔8個字節，而且單調遞增。

   2. 含義：

      1. 重作日誌的寫入總量，單位爲字節

         • 例如LSN數值爲1000，T1寫入100字節，則變爲1100，T2寫入200字節則變爲1300，以此類推，表明着redolog的寫入總量。

      2. checkpoint的位置

         • 經過單調增的LSN做爲版本號來判斷checkpoint點。

      3. 頁的版本

         • LSN不只存在於redolog中，也存在於每一個頁的頭部，頁頭部的FIL_PAGE_LSN值記錄了該頁的LSN，在頁中LSN表示該頁最後刷新時的LSN大小。能夠經過LSN判斷頁是否須要進行恢復操做。

5. 恢復

   • 概述：innodb引擎不管上次數據庫是否正常關閉，都是嘗試進行恢復，因爲checkpoint已經刷新到磁盤頁上到LSN，所以恢復過程當中，只須要恢復checkpoint開始到日誌部分。

3.2 undo

1. 做用：

   1. undo爲事務回滾提供支持，存放於數據庫內部的一個特殊段(segment)內，這個段稱爲undo段，位於表共享空間內。undo是邏輯日誌，所以只是將數據邏輯的恢復到原來到樣子，全部修改都被邏輯地取消了。例如對於每個insert，innodb引擎會完成一個delete，對於每一個update也有相反的update。
   2. undolog爲mvcc做數據支持，當用戶讀到一行被事務佔用的記錄時，能夠經過undolog實現非鎖定讀取。
   3. undolog也會產生redolog，undolog也須要持久性保護。

2. undo 存儲管理

   • innodb引擎有rollback segment，每一個回滾段記錄了1024個undolog segment，undo頁在undolog segment裏申請。
   • 事務提交時，將undo log放入列表中，以供purge操做。同時判斷undo log的頁是否能夠重用，若是能夠分配給下個事務使用。
   • 事務提交後並不會立刻刪除undo log及所在的頁，由於其餘事務可能須要經過undo log頁拿到行記錄以前的版本，是否能夠刪除須要purge線程來判斷。
   • 若爲每個事務都分配一個undo頁，空間浪費嚴重，故undo頁是能夠重用的，有可能出現一個undo頁裏存儲不一樣事務的undo log，故purge操做須要涉及磁盤的離散讀，是一個緩慢的過程。

3. undo log 格式

   1. insert undo log格式

      • insert undo log記錄的是全部插入數據，由於insert操做的記錄只對本事務可見，故在事務commit後不須要purge操做，直接刪除。

   2. update undo log格式

      • update undo log記錄的是delete和update操做的數據，該undolog可能須要提供對mvcc的支持，提交時放入undolog鏈表，等待purge線程刪除。

3.3 purge

• purge用於完成delete和update中delete的最終操做。

3.4 group commit

1. 概念

   • 若事務爲非只讀事務，則每次事務提交都須要一次fsync操做，所以保證重作日誌都寫入磁盤。爲了提升fsync性能，數據庫提供了group commit功能，即一次刷新確保多個事務日誌寫入文件。

2. BLGC Binary Log Group Commit

   • 開啓binlog後，爲了保證引擎層的事務和二進制文件的一致性，兩者之間使用了二階段事務。BLGC使用了一種leader-follower的方式，將事務提交氛圍Flush，Sync，Commit三個過程。

4. XA事務

5. 事務控制語句

6. 事務隔離級別

7. 分佈式事務