MySQL(InnoDB剖析):46---事務之（長事務）

長事務概述

• 長事務，就是執行時間較長的事務
• 比如，對于銀行系統的資料庫，每過一個階段可能需要更新對應賬戶的利息。如果對應賬号的數量非常大，例如對有1億使用者的表account，需要執行下列語句：

• 這時這個事務可能需要非常長的時間來完成。可能需要1個小時，也可能需要4、5個小時，這取決于資料庫的硬體配置
• DBA和開發人員本身能做的事情非常少。然而，由于事務的ACID的特性，這個操作被封裝在一個事務中完成。這就産生了一個問題，在執行過程中，當資料庫或作業系統、硬體等發生問題時，重新開始事務的代價非常多
• 資料庫需要復原所有已經發生的變化，而這個過程可能比産生這些變化的時間還要長。是以，對于長事務的問題，有時可以通過轉換為小批量的事務來進行處理。當事務發生錯誤時，隻需要復原一部分資料，然後接着上次已完成的事務繼續進行
• 例如，對于上面讨論的銀行利息問題，可以通過分解為小批量事務來完成，下面給出了僞代碼，既可以通過程式完成，也可以通過存儲過程完成：

• 上面代碼需要将處理1億使用者的大事務分解為每次處理10萬使用者的小事務，通過批量處理小事務來完成大事務的邏輯。每完成一個小事務，将完成的結果存在batchcontext表中，表示已完成批量事務的最大賬号ID。若事務在運作過程中産生問題，需要重做事務，可以從這個已完成的最大事務ID繼續進行批量的小事務，這樣重新開啟事務的代價就顯得比較低，頁更容易讓使用者接受。batchcontext表的另外一個好處是，在長事務的執行過程中，使用者知道在大概已經執行到哪個階段
• 這裡還有一個需要注意的地方，在從表account取得max_account_no時，人為地加上了一個共享鎖，以保證在事務的處理過程中，沒有其他事務可以來更新表中的資料