1.undo 日志序號

InnoDB 的事務對象有一個名為 undo_no 的屬性。事務每次改變（插入、更新、刪除）某個表的一條記錄，都會產生一條 undo 日志。這條 undo 日志中會存儲它自己的序號。這個序號就來源于事務對象的 undo_no 屬性。

也就是說，事務對象的 undo_no 屬性中保存著事務改變（插入、更新、刪除）某個表中下一條記錄產生的 undo 日志的序號。

每個事務都維護著各自獨立的 undo 日志序號，和其它事務無關。

每個事務的 undo 日志序號都從 0 開始。事務產生的第 1 條 undo 日志的序號為 0，第 2 條 undo 日志的序號為 1，依此類推。

2.savepoint 結構

我們通過 SQL 語句創建一個 savepoint 時，server 層、binlog、InnoDB 會各自創建用于保存 savepoint 信息的結構。

server 層的 savepoint 結構是一個 SAVEPOINT 類型的對象，主要屬性如下：

• prev：指向 server 層的 savepoint 鏈表中，上一次創建的 SAVEPOINT 對象。
• name：savepoint 的名字。
• mdl_savepoint：創建這個 savepoint 之前，事務加了哪些 MDL 鎖。 binlog 的 savepoint 結構很簡單，是一個 8 字節的整數。這個整數的值，是創建 savepoint 時事務已經產生的 binlog 日志的字節數，也是接下來新產生的 binlog 日志寫入 trx_cache 的 offset。

為了方便介紹，我們把這個整數值稱為 binlog offset。

InnoDB 的 savepoint 結構是一個 trx_named_savept_t 類型的對象，主要屬性如下：

• name：InnoDB 的 savepoint 名字。這個名字是 InnoDB 自己生成的，和 server 層的 SAVEPOINT 對象中保存的 savepoint 名字不一樣。
• savept：也是一個對象，類型為 trx_savept_t，里面保存著創建 savepoint 時，事務對象的 undo_no 屬性值。
• trx_savepoints：InnoDB 中多個 trx_named_savept_t 對象形成的鏈表。 創建 savepoint 時，server 層會分配一塊 96 字節的內存，除了存放它自己的 SAVEPOINT 對象，還會存放 binlog offset 和 InnoDB 的 trx_named_savept_t 對象。

server 層的 SAVEPOINT 對象占用這塊內存的前 48 字節，InnoDB 的 trx_named_savept_t 對象占用中間的 40 字節，binlog offset 占用最后的 8 字節。

圖片

3.查找同名 savepoint

客戶端連接到 MySQL 之后，MySQL 會分配一個專門用于該連接的用戶線程。

用戶線程中有一個 m_savepoints 鏈表，用戶創建的多個 savepoint 通過 prev 屬性形成鏈表，m_savepoints 就指向最新創建的 savepoint。

圖片

server 層創建 savepoint 之前，會按照創建時間從新到老，逐個查看鏈表中是否存在和本次創建的 savepoint 同名的 savepoint。

4.刪除同名 savepoint

如果在用戶線程的 m_savepoints 鏈表中找到了和本次創建的 savepoint 同名的 savepoint，需要先刪除 m_savepoints 鏈表中的同名 savepoint。

找到的同名 savepoint，是 server 層的 SAVEPOINT 對象，它后面的內存區域分別保存著 InnoDB 的 trx_named_savept_t 對象、binlog offset。

binlog 是個老實孩子，乖乖的把 binlog offset 寫入了 server 層為它分配的內存里。刪除同名 savepoint 時，不需要單獨處理 binlog offset。

InnoDB 就不老實了，雖然 server 層也為 InnoDB 的 trx_named_savept_t 對象分配了內存，但是 InnoDB 并沒有往里面寫入內容。

事務執行過程中，用戶每次創建一個 savepoint，InnoDB 都會創建一個對應的 trx_named_savept_t 對象，并加入 InnoDB 事務對象的 trx_savepoints 鏈表的末尾。

因為 InnoDB 自己維護了一個存放 savepoint 結構的鏈表，server 層刪除同名 savepoint 時，InnoDB 需要找到這個鏈表中對應的 savepoint 結構并刪除，流程如下：

• server 層把同名 savepoint 的 SAVEPOINT 對象后面分配給 trx_named_savept_t 對象的內存地址傳給 InnoDB。
• InnoDB 根據自己的算法把內存地址轉換為字符串，作為 InnoDB 的 savepoint 名字，到事務對象的 trx_savepoints 鏈表中找到對應的 trx_named_savept_t 對象，并從鏈表中刪除該對象。

InnoDB 從事務對象的 trx_savepoints 鏈表中刪除 trx_named_savept_t 對象之后，server 層接著從用戶線程的 m_savepoints 鏈表中刪除 server 層的 SAVEPOINT 對象，也就連帶著清理了 binlog offset。

5.保存 savepoint

處理完查找、刪除同名 savepoint 之后，server 層就正式開始創建 savepoint 了，這個過程分為 3 步。

第 1 步，binlog 會生成一個 Query_log_event。

以創建名為 test_savept 的 savepoint 為例，這個 event 的內容如下：

SAVEPOINT test_savept binlog event 寫入 trx_cache 之后，binlog offset 會寫入 server 層為它分配的 8 字節的內存中。

第 2 步，InnoDB 創建 trx_named_savept_t 對象，并放入事務對象的 trx_savepoints 鏈表的末尾。

圖片

trx_named_savept_t 對象的 name 屬性值是 InnoDB 的 savepoint 名字。這個名字是根據 server 層為 InnoDB 的 trx_named_savept_t 對象分配的內存的地址計算得到的。

trx_named_savept_t 對象的 savept 屬性，是一個 trx_savept_t 類型的對象。這個對象里保存著創建 savepoint 時，事務對象中 undo_no 屬性的值，也就是下一條 undo 日志的序號。

第 3 步，把 server 層的 SAVEPOINT 對象加入用戶線程的 m_savepoints 鏈表的尾部。

圖片

6.總結

server 層會創建一個 SAVEPOINT 對象，用于存放 savepoint 信息。

binlog 會把 binlog offset 寫入 server 層為它分配的一塊 8 字節的內存里。

InnoDB 會維護自己的 savepoint 鏈表，里面保存著 trx_named_savept_t 對象。

如果 m_savepoints 鏈表中存在和本次創建的 savepoint 同名的 savepoint， 創建新的 savepoint 之前，server 層會從鏈表中刪除這個同名的 savepoint。

server 層創建的 SAVEPOINT 對象會放入 m_savepoints 鏈表的末尾。

InnoDB 創建的 trx_named_savept_t 對象會放入事務對象的 trx_savepoints 鏈表的末尾。