MySQL · 引擎特性 · InnoDB 事務子係統介紹

前言

在前麵幾期關於InnoDB Redo和Undo實現的鋪墊後，本節我們從上層的角度來闡述InnoDB的事務子係統是如何實現的，涉及的內容包括：InnoDB的事務相關模塊，如何實現MVCC及ACID，如何進行事務的並發控製，事務係統如何進行管理等相關知識。本文的目的是讓讀者對事務係統有一個較全麵的理解。

由於不同版本對事務係統都有改變，本文的所有分析基於當前GA的最新版本MySQL5.7.9，但也會在闡述的過程中，順帶描述之前版本的一些內容。本文也會介紹5.7版本對事務係統的一些優化點。

另外盡管InnoDB鎖係統和事務有著非常密切的聯係，但鑒於本文主要介紹事務模塊，並且計劃中的篇幅已經足夠長。而鎖係統又是一個非常複雜的模塊，將在後麵的月報中單獨開一篇文章來講述。

在閱讀本文之前，強烈建議先閱讀下之前兩節的內容，因為事務係統和這些模塊有著非常緊密的聯係：

MySQL · 引擎特性 · InnoDB undo log 漫遊
 MySQL · 引擎特性 · InnoDB redo log漫遊
 MySQL · 引擎特性 · InnoDB 崩潰恢複過程

開啟事務

InnoDB提供了多種方式來開啟一個事務，最簡單的就是以一條BEGIN語句開始，也可以以START TRANSACTION開啟事務，你還可以選擇開啟一個隻讀事務還是讀寫事務。所有顯式開啟事務的行為都會隱式的將上一條事務提交掉。

所有顯示開啟事務的入口函數均為trans_begin，如下列出了幾種常用的事務開啟方式。

BEGIN

當以BEGIN開啟一個事務時，首先會去檢查是否有活躍的事務還未提交，如果沒有提交，則調用ha_commit_trans提交之前的事務。並釋放之前事務持有的MDL鎖。
執行BEGIN命令並不會真的去引擎層開啟一個事務，僅僅是為當前線程設定標記，表示為顯式開啟的事務。

和BEGIN等效的命令還有“BEGIN WORK”及“START TRANSACTION”

START TRANSACTION READ ONLY

使用該選項開啟一個隻讀事務，當以這種形式開啟事務時，會為當前線程的thd->tx_read_only設置為true。當Server層接受到任何數據更改的SQL時，都會直接拒絕請求，返回錯誤碼ER_CANT_EXECUTE_IN_READ_ONLY_TRANSACTION，不會進入引擎層。

這個選項可以強約束一個事務為隻讀的，而隻讀事務在引擎層可以走優化過的邏輯，相比讀寫事務的開銷更小，例如不用分配事務id，不用分配回滾段，不用維護到全局事務鏈表中。

該事務開啟的方式從5.6版本開始引入。我們知道，在MySQL5.6版本中引入的一個對事務模塊的重要優化：將全局事務鏈表拆成了兩個鏈表：一個用於維護隻讀事務，一個用於維護讀寫事務。這樣我們在構建一個一致性視圖時，隻需要遍曆讀寫事務鏈表即可。但是在5.6版本中，InnoDB並不具備事務從隻讀模式自動轉換成讀寫事務的能力，因此需要用戶顯式的使用以下兩種方式來開啟隻讀事務：

執行START TRANSACTION READ ONLY
或者將變量tx_read_only設置為true

5.7版本引入了模式自動轉換的功能，但該語法依然保留了。

另外一個有趣的點是，在5.7版本中，你可以通過設置session_track_transaction_info變量來跟蹤事務的狀態，這貨主要用於官方的分布式套件(例如fabric)，例如在一個負載均衡係統中，你需要知道哪些statement開啟或處於一個事務中，哪些statement允許連接分配器調度到另外一個connection。。隻讀事務是一種特殊的事務狀態，因此也需要記錄到線程的Transaction_state_tracker中。

關於Session tracker，可以參閱官方WL#6631

START TRANSACTION READ WRITE

和上述相反，該SQL用於開啟讀寫事務。這也是默認的事務模式。但有一點不同的是，如果當前實例的read_only打開了且當前連接不是超級賬戶，則顯示開啟讀寫事務會報錯。

同樣的事務狀態TX_READ_WRITE也要加入到Session Tracker中。另外包括上述幾種顯式開啟的事務，其標記TX_EXPLICIT也加入到session tracker中。

讀寫事務並不意味著一定在引擎層就被認定為讀寫事務了，5.7版本InnoDB裏總是默認一個事務開啟時的狀態為隻讀的。舉個簡單的例子，如果你事務的第一條SQL是隻讀查詢，那麼在InnoDB層，它的事務狀態就是隻讀的，如果第二條SQL是更新操作，就將事務轉換成讀寫模式。

START TRANSACTION WITH CONSISTENT SNAPSHOT

和上麵幾種方式不同的是，在開啟事務時還會順便創建一個視圖（Read View），在InnoDB中，視圖用於描述一個事務的可見性範圍，也是多版本特性的重要組成部分。

這裏會進入InnoDB層，調用函數innobase_start_trx_and_assign_read_view，注意隻有你的隔離級別設置成REPEATABLE READ（可重複讀）時，才會顯式開啟一個Read View，否則會拋出一個warning。

使用這種方式開啟事務時，事務狀態已經被設置成ACTIVE的。

狀態變量TX_WITH_SNAPSHOT會加入到Session Tracker中。

AUTOCOMMIT = 0

當autocommit設置成0時，就無需顯式開啟事務，如果你執行多條SQL但不顯式的調用COMMIT（或者執行會引起隱式提交的SQL）進行提交，事務將一直存在。通常我們不建議將該變量設置成0，因為很容易由於程序邏輯或使用習慣造成事務長時間不提交。而事務長時間不提交，在MySQL裏簡直就是噩夢，各種詭異的問題都會紛紛出現。一種典型的場景就是，你開啟了一條查詢，但由於未提交，導致後續對該表的DDL堵塞住，進而導致隨後的所有SQL全部堵塞，簡直就是災難性的後果。

另外一種情況是，如果你長時間不提交一個已經構建Read View的事務，purge線程就無法清理一些已經提交的事務鎖產生的undo日誌，進而導致undo空間膨脹。具體的表現為ibdata文件瘋狂膨脹。我們曾在線上觀察到好幾百G的Ibdata文件。

TIPS：所幸的是從5.7版本開始提供了可以在線truncate undo log的功能，前提是開啟了獨立的undo表空間，並保留了足夠的undo回滾段配置（默認128個），至少需要35個回滾段。其truncate原理也比較簡單：當purge線程發現一個undo文件超過某個定義的閥值時，如果沒有活躍事務引用這個undo文件，就將其設置成不可分配，並直接物理truncate文件。

提交事務

事務的提交分為兩種方式，一種是隱式提交，一種是顯式提交。

當你顯式開啟一個新的事務，或者執行一條非臨時表的DDL語句時，就會隱式的將上一個事務提交掉。另外一種就是顯式的執行“COMMIT” 語句來提交事務

然而，在不同的場景下，MySQL在提交時進行的動作並不相同，這主要是因為MySQL是一種服務器層-引擎層的架構，並存在兩套日誌係統：Binary log及引擎事務日誌。MySQL支持兩種XA事務方式：隱式XA和顯式XA；當然如果關閉binlog，並且僅使用一種事務引擎，就沒有XA可言了。

關於隱式XA的控製對象，在實例啟動時決定使用何種XA模式，如下代碼段：

  if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log))
  {
    if (opt_bin_log)
      tc_log= &mysql_bin_log;
    else
      tc_log= &tc_log_mmap;
  }

若打開binlog，且使用了事務引擎，則XA控製對象為mysql_bin_log
若關閉了binlog，且存在不止一種事務引擎時，則XA控製對象為tc_log_mmap
其他情況，使用tc_log_dummy，這種場景下就沒有什麼XA可言了，無需任何協調者來進行XA。

這三者是TC_LOG的子類，關係如下圖所示：

具體的，包含以下幾種類型的XA（不對數據產生變更的隻讀事務無需走XA）

Binlog/Engine XA

當開啟binlog時, MySQL默認使用該隱式XA模式。在5.7版本中，事務的提交流程包括：

- Binlog Prepare：
設置thd->durability_property= HA_IGNORE_DURABILITY, 表示在innodb prepare時，不刷redo log

- InnoDB Prepare （入口函數innobase_xa_prepare --> trx_prepare）：
更新InnoDB的undo回滾段，將其設置為Prepare狀態（TRX_UNDO_PREPARED）

- 進入組提交(ordered_commit)

Flush Stage：此時形成的一組隊列，有leader依次為別的線程寫binlog文件
在準備寫binlog前，會調用ha_flush_logs接口，將存儲的日誌寫到最新的LSN，然後再寫binlog到文件。這樣做的目的是為了提升組提交的效率，具體參閱之我寫的一篇月報

Sync Stage：如果sync_binlog計數超過配置值，則進行一次文件fsync，注意，參數sync_binlog的含義不是指的這麼多個事務之後做一次fsync，而是這麼多“組”事務隊列後做一次fsync。

Semisync Stage (RDS MySQL only)：如果我們在事務commit之前等待備庫ACK（設置成AFTER_SYNC模式），用戶線程會釋放上一個stage的鎖，並等待ACk。這意味著在等待ACK的過程中，我們並不堵塞上一個stage的binlog寫入，可以增加一定的吞吐量。

Commit Stage：隊列中的事務依次進行innodb commit，將undo頭的狀態修改為TRX_UNDO_CACHED/TRX_UNDO_TO_FREE/TRX_UNDO_TO_PURGE任意一種 (undo相關知識參閱之前的月報)；並釋放事務鎖，清理讀寫事務鏈表、readview等一係列操作。每個事務在commit階段也會去更新事務頁的binlog位點。

TIPS：如果你關閉了binlog_order_commits選項，那麼事務就各自進行提交，這種情況下不能保證innodb commit順序和binlog寫入順序一致，這不會影響到數據一致性，在高並發場景下還能提升一定的吞吐量。但可能影響到物理備份的數據一致性，例如使用xtrabackup（而不是基於其上的innobackup腳本）依賴於事務頁上記錄的binlog位點，如果位點發生亂序，就會導致備份的數據不一致。

Engine/Engine XA

當binlog關閉時，如果事務跨引擎了，就可以在事務引擎間進行XA了，典型的例如InnoDB和Tokudb（在RDS MySQL裏已同時支持這兩種事務引擎）。當支持超過1種事務引擎時，並且binlog關閉了，就走TC LOG MMAP邏輯。對應的XA控製對象為tc_log_mmap。

由於需要持久化事務信息以用於重啟恢複，因此在該場景下，tc_log_mmap模塊會創建一個文件，名為tc.log，文件初始化大小為24KB，使用mmap的方式映射到內存中。

tc.log 以PAGE來進行劃分，每個PAGE大小為8K，至少需要3個PAGE，初始化的文件大小也為3個PAGE（TC_LOG_MIN_SIZE），每個Page對應的結構體對象為st_page，因此需要根據page數，完成文件對應的內存控製對象的初始化。初始化第一個page的header，寫入magic number以及當前的2PC引擎數（也就是total_ha_2pc）

下圖描述了tc.log的文件結構：

在事務執行的過程中，例如遇到第一條數據變更SQL時，會注冊一個唯一標識的XID（實際上通過當前查詢的query_id來唯一標識），之後直到事務提交，這個xid都不會改變。事務引擎本身在使用undo時，必須加上這個XID標識。

在進行事務Prepare階段，若事務涉及到多個引擎，先在各自引擎裏做事務Prepare。

然後進入commit階段，這時候會將xid記錄到tc.log中（如上圖所示），這類涉及到相對複雜的page選擇流程，這裏不展開描述，具體的參閱函數TC_LOG_MMAP::commit

在完成記錄到tc.log後，就到引擎層各自提交事務。這樣即使在引擎提交時失敗，我們也可以在crash recovery時，通過讀取tc.log記錄的xid，指導引擎層相符合xid的事務進行提交。

Engine Commit

當關閉binlog時，且事務隻使用了一個事務引擎時，就無需進行XA了，相應的事務commit的流程也有所不同。

首先事務無需進入Prepare狀態，因為對單引擎事務做XA沒有任何意義。

其次，因為沒有Prepare狀態的保護，事務在commit時需要對事務日誌進行持久化。這樣才能保證所有成功返回的事務變更，能夠在崩潰恢複時全部完成。

顯式XA

MySQL支持顯式的開啟一個帶命名的XA事務，例如：

XA BEGIN "xidname"
     do something.....
XA END 'xidname'
XA PREPARE 'xidname'   // 當完成這一步時，如果崩潰恢複，是可以在啟動後通過XA RECOVER獲得事務信息，並進行顯式提交。
XA COMMIT 'xidname'  // 完全提交事務

一個有趣的問題是，在5.7之前的版本中，如果執行XA的過程中，在完成XA PREPARE後，如果kill掉session，事務就丟失了，而不是像崩潰恢複那樣，可以直接恢複出來。這主要是因為MySQL對Kill session的行為處理是直接回滾事務。

為了解決這個問題，MySQL5.7版本做了不小的改動，將XA的兩階段都記錄到了binlog中。這樣狀態是持久化了的，一次幹淨的shutdown後，可以通過掃描binlog恢複出XA事務的狀態，對於kill session導致的XA事務丟失，邏輯則比較簡單：內存中使用一個transaction_cache維護了所有的XA事務，在斷開連接調用THD::cleanup時不做回滾，僅設置事務標記即可。

具體的參閱我之前寫的這篇月報

事務回滾

當由於各種原因（例如死鎖，或者顯式ROLLBACK）需要將事務回滾時，會調用handler接口ha_rollback_low，進而調用InnoDB函數trx_rollback_for_mysql來回滾事務。回滾的方式是提取undo日誌，做逆向操作。

由於InnoDB的undo是單獨寫在表空間中的，本質上和普通的數據頁是一樣的。如果在事務回滾時，undo頁已經被從內存淘汰，回滾操作（特別是大事務變更回滾）就可能伴隨大量的磁盤IO。因此InnoDB的回滾效率非常低。有的數據庫管理係統，例如PostgreSQL，通過在數據頁上冗餘數據產生版本鏈的方式來實現多版本，因此回滾起來非常方便，隻需要設置標記即可，但額外帶來的問題就是無效數據清理開銷。

SavePoint管理

在事務執行的過程中，你可以通過設置SAVEPOINT的方式來管理事務的執行過程。

在介紹Savepoint之前，需要先介紹下trx_t::undo_no。在事務每次成功寫入一次undo後，這個計數都會遞增一次（參閱函數trx_undo_report_row_operation）。事務的undo_no也會記錄到undo page中進行持久化。因此在undo鏈表上的undo_no總是有序遞增的。

總的來說，主要有以下幾種操作類型。

設置SAVEPOINT

語法： SAVEPOINT sp_name

入口函數：trans_savepoint

在事務中設置一個SAVEPOINT，你可以隨意命名一個名字，在事務中設置的所有savepoint實際上維護了兩份鏈表，一份掛在THD變量上（thd->get_transaction()->m_savepoints），包含了基本的savepoint信息及到引擎層的映射，另一份在引擎層的事務對象上（維持鏈表trx_t::trx_savepoints中）。

如下圖所示：

總共分為以下幾步：
0. 在增加新的SAVEPOINT時，總是先判斷下是否同名的SAVEPOINT已經存在，如果存在，就用後者替換前者。
1. Server層維護的savepoint信息記錄了命名信息及MDL鎖的savepoint點。其中MDL鎖的savepoint，可以實現回滾操作時釋放該savepoint之後再獲得的MDL鎖。
2. 在當前線程的Binlog cache中寫入設置Savepoint的SQL, 並保存binlog cache中的位點（binlog_savepoint_set）。
3. 引擎層的savepoint中記錄了最近一次的trx_t::undo_no及SAVEPOINT名字。通過這些信息可以準確的定位在設置SAVEPOINT點時Undo位點。（參閱引擎層入口函數：trx_savepoint_for_mysql）

回滾SAVEPOINT

語法： ROLLBACK TO [ SAVEPOINT ] sp_name
入口函數：trans_rollback_to_savepoint

檢查點的回滾主要包括：
0. 如果事務是一個XA事務，且已經處於XA PREPARE狀態時是不允許回滾到某個SAVEPOINT的。
1. 如果涉及非事務引擎，在binlog中寫入回滾SQL，否則直接將binlog cache truncate到之前設置sp時保存的位點。（binlog_savepoint_rollback）
2. 在引擎層進行回滾（trx_rollback_to_savepoint_for_mysql）
根據之前記錄的undo_no，可以逆向操作當前事務占用的undo slot上的undo記錄來進行回滾。
3. 判斷是否允許回滾MDL鎖：

binlog關閉的情況下，總是允許回滾MDL鎖
或者由引擎來確認（ha_rollback_to_savepoint_can_release_mdl），同時滿足：
- InnoDB：如果當前事務不持有任何事務鎖（表級或者行級），則認為可以回滾MDL鎖。
- Binlog：如果沒有更改非事務引擎，則可以釋放MDL鎖。如果允許回滾MDL，則通過之前記錄的st_savepoint::mdl_savepoint進行回滾

釋放SAVEPOINT

語法為： RELEASE SAVEPOINT sp_name
入口函數：trans_rollback_to_savepoint

顧名思義，就是刪除一個SAVEPOINT，操作也很簡單，直接根據命名從server層和innodb層的清理掉，並釋放對應的內存。

隱式SAVEPOINT

在InnoDB中，還有一種隱式的savepoint，通過變量trx_t::last_sql_stat_start來維護。

初始狀態下trx_t::last_sql_stat_start的值為0，當執行完一條SQL時，會調用函數trx_mark_sql_stat_end將當前的trx_t::undo_no保存到trx_t::last_sql_stat_start中。

如果SQL執行失敗，就可以據此進行statement級別的回滾操作（trx_rollback_last_sql_stat_for_mysql）。

無論是顯式SAVEPOINT還是隱式SAVEPOINT，都是通過undo_no來指示回滾到哪個事務狀態。

兩個有趣的bug

bug#79493

在一個隻讀事務中，如果設置了SAVEPOINT，任意執行一次ROLLBACK TO SAVEPOINT都會將事務從隻讀模式改變成讀寫模式。這主要是因為在活躍事務中執行ROLLBACK 操作會強製轉換READ-WRITE模式。實際上這是沒必要的，因為並沒有造成任何的數據變更。

bug#79596

這個bug可以認為是一個相當嚴重的bug：在一個活躍的做過數據變更操作的事務中，任意執行一次ROLLBACK TO SAVEPOINT（即使SAVEPOINT不存在），然後kill掉客戶端，會發現事務卻提交了，並且沒有寫到binlog中。這會導致主備的數據不一致。

重現步驟如下：

mysql> create table test (value int) engine=innodb;
Query OK, 0 rows affected (3.88 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test set value = 1;
Query OK, 1 row affected (4.43 sec)

mysql> rollback to savepoint tx_0;
ERROR 1305 (42000): SAVEPOINT tx_0 does not exist
mysql> Killed

最後一步直接對session的進程kill -9時會導致事務commit。這主要是因為如果直接kill客戶端，服務器端在清理線程資源，進行事務回滾時，相關的變量並沒有被重設，thd的command類型還是SQLCOM_ROLLBACK_TO_SAVEPOINT，在函數MYSQL_BIN_LOG::rollback函數中將不會調用ha_rollback_low的引擎層回滾邏輯。原因是回滾到某個savepoint有特殊的處理流程，

如果是通過ctrl+c的方式關閉client段，實際上會發送一個類型為COM_QUIT的command，它會將thd->lex->sql_command設置為SQLCOM_END，這時候會走正常的回滾邏輯。

事務執行管理

在事務執行的過程中，需要多個模塊來輔助事務的正常執行：

Server層的MDL鎖模塊，維持了一個事務過程中所有涉及到的表級鎖對象。通過MDL鎖，可以堵塞DDL，避免DDL和DML記錄binlog亂序；
InnoDB的trx_sys子係統，維持了所有的事務狀態，包括活躍事務，非活躍事務對象，讀寫事務鏈表，負責分配事務id，回滾段，Readview等信息，是事務係統的總控模塊；
InnoDB的lock_sys子係統，維護事務鎖信息，用於對修改數據操作做並發控製，保證了在一個事務中被修改的記錄，不可以被另外一個事務修改；
InnoDB的log_sys子係統，負責事務redo日誌管理模塊，
InnoDB的purge_sys子係統，則主要用於在事務提交後，進行垃圾回收，以及數據頁的無效數據清理。

總的來說，事務管理模塊的架構圖，如下圖所示：

下麵就幾個事務模塊的關鍵點展開描述。

事務ID

在InnoDB一直維持了一個不斷遞增的整數，存儲在trx_sys->max_trx_id中；每次開啟一個新的讀寫事務時，都將該id分配給事務，同時遞增全局計數。事務id可以看做一個事務的唯一標識。

在MySQL5.6及之前的版本中，總是為事務分配ID。但實際上這是沒有必要的，畢竟隻有做過數據更改的讀寫事務，我們才需要去根據事務id判斷可見性。因此在MySQL5.7版本中，隻有讀寫事務才會分配事務id，隻讀事務的id默認為0。

那麼問題來了，怎麼去區分不同的隻讀事務呢？這裏在需要輸出事務id時（例如執行SHOW ENGINE INNODB STATUS 或者查詢INFORMATION_SCHEMA.INNODB_TRX表），使用隻讀事務對象的指針或上一個常量來標識其唯一性，具體的計算方式見函數trx_get_id_for_print。所以如果你show出來的事務id看起來數字特別龐大，千萬不要驚訝。

對於全局最大事務id，每做256次賦值(TRX_SYS_TRX_ID_WRITE_MARGIN)就持久化一次到ibdata的事務頁(TRX_SYS_PAGE_NO)中。

已分配的事務Id會加入到全局讀寫事務Id集合中（trx_sys->rw_trx_ids），事務Id和事務對象的map加入到trx_sys->rw_trx_set中，這是個有序的集合(std::set)，可以用於通過trx id快速定位到對應的事務對象。

事務分配得到的ID並不是立刻就被使用了，而是在做了數據修改時，需要創建或重用一個undo slot時，會將當前事務的id寫入到undo page頭，狀態為TRX_UNDO_ACTIVE。這也是崩潰恢複時，InnoDB判斷是否有未完成事務的重要依據。

在執行數據更改的過程中，如果我們更新的是聚集索引記錄，事務ID + 回滾段指針會被寫到聚集索引記錄中，其他會話可以據此來判斷可見性以及是否要回溯undo鏈。
對於普通的二級索引頁更新, 則采用回溯聚集索引頁的方式來判斷可見性（如果需要的話）。關於MVCC，後文會有單獨描述。

事務鏈表和集合

事務子係統維護了三個不同的鏈表，用來管理事務對象

trx_sys->mysql_trx_list
包含了所有用戶線程的事務對象，即使是未開啟的事務對象，隻要還沒被回收到trx_pool中，都被放在該鏈表上。當session斷開時，事務對象從鏈表上摘取，並被回收到trx_pool中，以待重用。

trx_sys->rw_trx_list
讀寫事務鏈表，當開啟一個讀寫事務，或者事務模式轉換成讀寫模式時，會將當前事務加入到讀寫事務鏈表中，鏈表上的事務是按照trx_t::id有序的；在事務提交階段將其從讀寫事務鏈表上移除。

trx_sys->serialisation_list
序列化事務鏈表，在事務提交階段，需要先將事務的undo狀態設置為完成，在這之前，獲得一個全局序列號trx->no，從trx_sys->max_trx_id中分配，並將當前事務加入到該鏈表中。隨後更新undo等一係列操作後，因此進入提交階段的事務並不是trx->id有序的，而是根據trx->no排序。當完成undo更新等操作後，再將事務對象同時從serialisation_list和rw_trx_list上移除。

這裏需要說明下trx_t::no，這是個不太好理清的概念，從代碼邏輯來看，在創建readview時，會用到序列化鏈表，鏈表的第一個元素具有最小的trx_t::no，會賦值給ReadView::m_low_limit_no。purge線程據此創建的readview，隻有小於該值的undo，才可以被purge掉。

總的來說，mysql_trx_list包含了rw_trx_list上的事務對象，rw_trx_list包含了serialisation_list上的事務對象。

事務ID集合有兩個：
trx_sys->rw_trx_ids
記錄了當前活躍的讀寫事務ID集合，主要用於構建ReadView時快速拷貝一個快照

trx_sys->rw_trx_set
這是的映射集合，根據trx_id排序，用於通過trx_id快速獲得對應的事務對象。一個主要的用途就是用於隱式鎖轉換，需要為記錄中的事務id所對應的事務對象創建記錄鎖，通過該集合可以快速獲得事務對象

事務回滾段

對於普通的讀寫事務，總是為其指定一個回滾段（默認128個回滾段）。而對於隻讀事務，如果使用到了InnoDB臨時表，則為其分配(1~32)號回滾段。（回滾段指定參閱函數trx_assign_rseg_low）

當為事務指定了回滾段後，後續在事務需要寫undo頁時，就從該回滾段上分別分配兩個slot，一個用於update_undo，一個用於insert_undo。分別處理的原因是事務提交後，update_undo需要purge線程來進行回收，而insert_undo則可以直接被重利用。

關於undo相關知識可以參閱之前的月報

事務引用計數

在介紹事務引用計數之前，我們首先要了解下什麼是隱式鎖。所謂隱式鎖，其實並不是一個真正的事務鎖對象，可以理解為一個標記：對於聚集索引頁的更新，記錄本身天然帶事務id，對於二級索引頁，則在page上記錄最近一次更新的最大事務id，通過回表的方式判斷可見性。

由於事務鎖涉及到全局資源，創建鎖的開銷高昂，InnoDB對於新插入的記錄，在沒有衝突的情況下是不創建記錄鎖的。舉個例子，Session 1插入一條記錄，並保持未提交狀態。另外一個session想更新這條記錄，從數據頁上讀取到這條記錄後，發現對應的事務id還處於活躍狀態，根據當前的並發規則，這個更新需要被阻塞住。因此第二個session需要為session 1創建一條記錄鎖，然後將自己放入等待隊列中。

在MySQL5.7版本之前，隱式鎖轉換的邏輯為（函數lock_rec_convert_impl_to_expl）
1. 首先判斷記錄對應的事務ID是否還處於活躍狀態
聚集索引： lock_clust_rec_some_has_impl
二級索引： lock_sec_rec_some_has_impl
如果不活躍，說明事務已提交，我們可以對這條記錄做任何更改操作。直接返回
否則返回獲取的trx_id
2. 持有lock_sys->mutex；
3. 持有trx_sys->mutex ，並獲取當前記錄中的事務id對應的內存事務對象trx_t
4. 為該事務創建一個鎖對象，並加入到鎖隊列中。
5. 釋放lock_sys->mutex

上述流程中長時間持有lock_sys->mutex，目的是防止在為其轉換隱式鎖為顯式鎖時事務被提交掉。尤其是在第三步，同時持有兩把大鎖去查找事務對象。在5.6官方版本中，這種查找操作還需要遍曆鏈表，開銷巨大，推高了臨界資源的競爭。

因此在5.7中引入事務計數trx_t::n_ref來輔助判斷，在隱式鎖轉換時，通過讀寫事務集合(rw_trx_set)快速獲得事務對象，同時對trx_t::n_def遞增。這個過程無需加lock_sys->mutex鎖。隨後再持有Lock_sys->mutex去創建顯式鎖。在完成創建後，遞減trx_t::n_ref。

為了防止為一個已提交的事務創建顯式鎖；在事務提交階段也做了處理：在事務釋放事務鎖之前，如果引用計數非0，則表示有人正在做隱式鎖轉換，這裏需要等待其完成。(參考函數lock_trx_release_locks)。

實際上上述修改是在官方優化讀寫事務鏈表之前完成的。由於在5.7裏已經使用一個有序的集合保存了trx_id到trx_t的關聯，可以非常快速的定位到事務對象，這個優化帶來的性能提升已經沒那麼明顯了。

關於隱式鎖更詳細的信息，我們將在之後專門講述“事務鎖”的月報中再單獨描述。

事務並發控製

在MySQL5.7中，由於消除了大量臨界資源的競爭，InnoDB隻讀查詢的性能非常優化，幾乎可以隨著CPU線性擴展。但如果進入到讀寫混合的場景，就不可避免的使用到一些臨界資源，例如事務、鎖、日誌等子係統。當競爭越激烈，就可能導致性能的下降。通常係統會有個吞吐量和響應時間最優的性能拐點。

InnoDB本身提供了並發控製機製，一種是語句級別的並發控製，另外一種是事務提交階段的並發控製。

語句級別的並發通過參數innodb_thread_concurrency來控製，表示允許同時在InnoDB層活躍的並發SQL數。

每條SQL在進入InnoDB層進行操作之前都需要先遞增全局計數，並為當前sql分配innodb_concurrency_tickets個ticket。也就是說，如果當前sql需要進出InnoDB層很多次（例如一個大查詢需要掃描很多行數據時），innodb_concurrency_tickets次都可以自由進入InnoDB，無需判斷innodb_thread_concurrency。當ticket用完時，就需要重新進入。當SQL執行完成後，會將ticket重置為0。

如果當前InnoDB層的並發度已滿，用戶線程就需要等待，目前的實現使用sleep一段時間的方式，sleep的時間是自適應的，但你可以通過參數innodb_adaptive_max_sleep_delay來設置一個最多大sleep事件，具體的算法參閱函數srv_conc_enter_innodb_with_atomics。

提到並發控製，另外一個不得不提的問題就是熱點更新問題。事務在進入InnoDB層，準備更新一條數據，但發現行記錄被其他線程鎖住，這時候該線程會強製退出innodb並發控製，同時將自己suspend住，進入睡眠等待。如果有大量並發的更新同一條記錄，就意味著大量線程進入InnoDB層，訪問熱點競爭資源鎖係統，然後再退出。最終會呈現出大量線程在innodb中suspend住，相當於並發控製並沒有達到降低臨界資源爭用的效果。早期我們對該問題的優化就是將線程從堵在innodb層，轉移到堵在進入innodb層時的外部排隊中，這樣就不涉及到InnoDB的資源爭用了。具體的實現是將statement級別的並發控製提升為事務級別的並發控製，因此這個方案的缺陷是對長事務不友好。

另外還有一些並發控製方案，例如線程池、水位限流、按pk排隊等策略，我們的RDS MySQL也很早就支持了。如果你存在熱點爭用（例如秒殺場景），並且正在使用RDS MySQL，你可以去谘詢售後如何使用這些特性。

除了語句級別的並發外，InnoDB也提供了提交階段的並發控製，主要通過參數innodb_commit_concurrency來控製。該參數的默認值為0，表示不控製commit階段的並發。在進入函數innobase_commit時，如果該參數被設置，且當前並發度超過，就需要等待。然而由於當前在默認配置下所有事務都走組提交(ordered_commit)，innodb層的提交大多數情況下隻會有一個活躍線程。你隻有關閉binlog或者關閉參數binlog_order_commits，這個參數設置才有意義。

高優先級事務

MySQL5.7 實現了一種高優先級的事務調度方式。當事務處於高優先級模式時，它將永遠不會被選作deadlock場景的犧牲者，擁有獲得鎖的最高優先級，並能kill掉阻塞它的的優先級事務。這個特性主要是為了支持官方開發的Group Replication Plugin套件，以保證事務總是能在所有的節點上提交。

如何使用
目前GA版本還沒有提供公共接口來使用該功能，但代碼實現都是完備的，如果想使用該功能，直接寫一個設置變量的接口即可，非常簡單。
在server層，每個THD上新增了兩個變量來標識事務的優先級：

THD::tx_priority 事務級別有效，當兩個事務在innodb層衝突時，擁有更高值的事務將贏得鎖
THD::thd_tx_priority 線程級別有效，當該變量被設置時，選擇該值作為事務優先級，否則選擇tx_priority

死鎖檢測
在進行死鎖檢測時，需要對死鎖的兩個事務的優先級進行比較，低優先級的總是會被優先回滾掉，以保證高優先級的事務正常執行（DeadlockChecker::check_and_resolve）

處理鎖等待
在對記錄嚐試加鎖時，如果發現有別的事務和當前事務衝突（lock_re_other_has_conflicting），需要判斷是否要加入到等待隊列中（RecLock::add_to_wait）：

如果兩個事務都設置了高優先級、但當前事務優先級較低，或者衝突的事務是一個後台進程開啟的事務（例如dict_stat線程進行統計信息更新），則立刻失敗該事務，並返回DB_DEADLOCK錯誤碼
嚐試將當前鎖對象加入到等待隊列中(RecLock::enqueue_priority)，高優先級的事務可以跳過鎖等待隊列(RecLock::jump_queue)，被跳過的事務需要被標記為異步回滾狀態（RecLock::mark_trx_for_rollback），搜集到當前事務的trx_t::hit_list鏈表中。當阻塞當前事務的另外一個事務也處於等待狀態、但等待另外一個不同的記錄鎖時，調用rollback_blocking_trx直接回滾掉，否則在進入鎖等待之前再調用trx_kill_blocking依次回滾。

這裏涉及到事務鎖模塊，本文不展開描述，下次專門在事務鎖相關主題的月報講述，你可以通過官方WL#6835 獲取更多關於高優先級事務的信息

trx_t::flush_observer

閱讀代碼時發現這個在5.7版本新加的變量，從它的命名可以看出，其應該和髒頁flush相關。flush_observer可以認為是一個標記，當某種操作完成時，對於帶這種標記的page(buf_page_t::flush_observer)，需要保證完全刷到磁盤上。

該變量主要解決早期5.7版本建索引耗時太久的bug#74472：為表增加索引的操作非常慢，即使表上沒幾條數據。原因是innodb在5.7版本修正了建索引的方式，采用自底向上的構建方式，並在創建索引的過程中關閉了redo，因此在做完加索引操作後，必須將其產生的髒頁完全寫到磁盤中，才能認為索引構建完畢，所以發起了一次完全的checkpoint，但如果buffer pool中存在大量髒頁時，將會非常耗時。

為了解決這一問題，引入了flush_observer，在建索引之前創建一個FlushObserver並分配給事務對象(trx_set_flush_observer)，同時傳遞給BtrBulk::m_flush_observer。

在構建索引的過程中產生的髒頁，通過mtr_commit將髒頁轉移到flush_list上時，順便標記上flush_observer（add_dirty_page_to_flush_list —> buf_flush_note_modification）

當做完索引構建操作後，由於bulk load操作不記redo，需要保證DDL產生的所有髒頁都寫到磁盤，因此調用FlushObserver::flush，將髒頁寫盤（buf_LRU_flush_or_remove_pages）。在做完這一步後，才開始apply online ddl過程中產生的row log(row_log_apply)。

如果DDL被中斷（例如session被kill），也需要調用FlushObserver::flush，將這些產生的髒頁從內存移除掉，無需寫盤。

事務對象池

為了減少構建事務對象時的內存操作開銷，尤其是短連接場景下的性能，InnoDB引入了一個池結構，可以很方便的分配和釋放事務對象。實際上事務的事務鎖對象也引用了池結構。

事務池對應的全局變量為trx_pools，初始化為：

     trx_pools = UT_NEW_NOKEY(trx_pools_t(MAX_TRX_BLOCK_SIZE));

trx_pools是操作trx pool的接口，類型為trx_pools_t，其定義如下：

     typedef Pool<trx_t, TrxFactory, TrxPoolLock> trx_pool_t;
     typedef PoolManager<trx_pool_t, TrxPoolManagerLock > trx_pools_t;

其中,trx_t表示事務對象類型，TrxFactory封裝了事務的初始化和，TrxPoolLock封裝了POOL鎖的創建，銷毀，加鎖，解鎖。
PoolManager封裝了池的管理方法

這裏涉及到多個類：

Pool 及 PoolManager 是公共用的類
TrxFactory 和 TrxPoolLock, TrxPoolManagerLock是trx pool私有的類。
TrxFactory用於定義池中事務對象的初始化和銷毀動作；
TrxPoolLock用於定義每個池中對象的互斥鎖操作；
由於POOL的管理結構支持多個POOL對象， TrxPoolManagerLock用於互斥操作增加POOL對象。支持多個POOL對象的目的是分拆單個POOL對象的鎖開銷，避免引入熱點。因為從POOL中獲取和返還對象，都是需要排他鎖的。

相關類的關係如下圖所示：

InnoDB MVCC實現

InnoDB有兩個非常重要的模塊來實現MVCC，一個是undo日誌，用於記錄數據的變化軌跡，另外一個是Readview，用於判斷該session對哪些數據可見，哪些不可見。實際上我們已經在之前的月報中介紹過這部分內容，這裏再簡要介紹下。

事務視圖ReadView

前麵已經多次提到過ReadView，也就是事務視圖，它用於控製數據的可見性，在InnoDB中，隻有查詢才需要通過Readview來控製可見性，對於DML等數據變更操作，如果操作了不可見的數據，則直接進入鎖等待。

ReadView包含幾個重要的變量：

ReadView::id 創建該視圖的事務id
ReadView::m_ids 創建readview時，活躍的讀寫事務id數組，有序存儲
ReadView::m_low_limit_id 設置為當前最大事務id
ReadView::m_up_limit_id m_ids集合中的最小值，如果m_ids集合為空，表示當前沒有活躍讀寫事務，則設置為當前最大事務id

很顯然ReadView的創建需要在trx_sys->mutex的保護下進行，相當於拿到了當時的一個全局事務快照。基於上述變量，我們就可以判斷數據頁上的記錄是否對當前事務可見了。

為了管理ReadView，MVCC子係統使用多個鏈表進行分配、維護、回收Readview

MVCC::m_free 用於維護空閑的readview對象，初始化時創建1024個ReadView對象（trx_sys_create），當釋放一個活躍的視圖時，會將其加到該鏈表上，以便下次重用。
MVCC::m_views 這裏存儲了兩類視圖，一類是當前活躍的視圖，另一類是上次被關閉的隻讀事務視圖。後者主要是為了減少視圖分配開銷。因為當係統的讀占大多數時，如果在兩次查詢中間沒有進行過任何讀寫操作，那我們就可以重用這個readview，而無需去持有trx_sys->mutex鎖重新分配。目前自動提交的隻讀事務或者RR級別下的隻讀都支持read view緩存，但目前版本還存在的問題是，在RC級別下不支持視圖緩存，見bug#79005

另外purge係統在開始purge任務時，需去克隆MVCC::m_views鏈表上未被close的最老視圖，並在本地視圖中將該最老事務的事務id也加入到不可見的事務id集合ReadView::m_ids中(MVCC::clone_oldest_view)

回滾段指針

回滾段undo是實現InnoDB MVCC的根基。每次修改聚集索引頁上的記錄時，變更之前的記錄都會寫到undo日誌中。回滾段指針包括undo log所在的回滾段id、日誌所在的page no、以及page內的偏移量，可以據此找到最近一次修改之前的undo記錄，而每條Undo記錄又能再次找到之前的變更。

當有可能undo被訪問到時，Purge_sys將不會去清理undo log，如上所述，purge_sys隻會去清理最老readview不會看到的事務。這意味著，如果你運行了一個長時間的查詢SQL，或者以大於RC的隔離級別開啟了一個事務視圖但沒有提交事務，Purge係統將一直無法前行，即使你的會話並不活躍。這時候undo日誌將無法被及時回收，最直觀的後果就是undo空間急劇膨脹。

關於undo這裏不贅述，詳細參閱之前月報

可見性判斷

如上所述，聚集索引的可見性判斷和二級索引的可見性判斷略有不同。因為二級索引記錄並沒有存儲事務id信息，相應的，隻是在數據頁頭存儲了最近更新該page的trx_id。

對於聚集索引記錄，當我們從btree獲得一條記錄後，先判斷（lock_clust_rec_cons_read_sees）當前的readview是否滿足該記錄的可見性：

如果記錄的trx_id小於ReadView::m_up_limit_id，則說明該事務在創建readview時已經提交了，肯定可見
如果記錄的trx_id大於等於ReadView::m_low_limit_id，則說明該事務是創建readview之後開啟的，肯定不可見。
當trx_id在m_up_limit_id和m_low_limit_id之間時，如果在ReadView::m_ids數組中，說明創建readview時該事務是活躍的，其做的變更對當前視圖不可見，否則對該trx_id的變更可見。

如果基於上述判斷，該數據變更不可見時，就嚐試通過undo去構建老版本記錄（row_sel_build_prev_vers_for_mysql -->row_vers_build_for_consistent_read），直到找到可見的記錄，或者到達undo鏈表頭都未找到。

注意當隔離級別設置為READ UNCOMMITTED時，不會去構建老版本。

如果我們查詢得到的是一條二級索引記錄：

首先將page頭的trx_id和當前視圖相比較：如果小於ReadView::m_up_limit_id，當前事務肯定可見；否則就需要去找到對應的聚集索引記錄（lock_sec_rec_cons_read_sees）。
如果需要進一步判斷，先根據ICP條件，檢查是否該記錄滿足push down的條件，以減少回聚集索引的次數。
滿足ICP條件，則需要查詢聚集索引記錄（row_sel_get_clust_rec_for_mysql），之後的判斷就和上述聚集索引記錄的判斷一致了

在InnoDB中，隻有讀查詢才會去構建ReadView視圖，對於類似DML這樣的數據更改，無需判斷可見性，而是單純的發現事務鎖衝突，直接堵塞操作。

隔離級別

然而在不同的隔離級別下，可見性的判斷有很大的不同。

READ-UNCOMMITTED
在該隔離級別下會讀到未提交事務所產生的數據更改，這意味著可以讀到髒數據，實際上你可以從函數row_search_mvcc中發現，當從btree讀到一條記錄後，如果隔離級別設置成READ-UNCOMMITTED，根本不會去檢查可見性或是查看老版本。這意味著，即使在同一條SQL中，也可能讀到不一致的數據。
READ-COMMITTED
在該隔離級別下，可以在SQL級別做到一致性讀，當事務中的SQL執行完成時，ReadView被立刻釋放了，在執行下一條SQL時再重建ReadView。這意味著如果兩次查詢之間有別的事務提交了，是可以讀到不一致的數據的。
REPEATABLE-READ
可重複讀和READ-COMMITTED的不同之處在於，當第一次創建ReadView後（例如事務內執行的第一條SEELCT語句），這個視圖就會一直維持到事務結束。也就是說，在事務執行期間的可見性判斷不會發生變化，從而實現了事務內的可重複讀。
SERIALIZABLE
序列化的隔離是最高等級的隔離級別，當一個事務在對某個表做記錄變更操作時，另外一個查詢操作就會被該操作堵塞住。同樣的，如果某個隻讀事務開啟並查詢了某些記錄，那麼另外一個session對這些記錄的更改操作是被堵塞的。內部的實現其實很簡單：
- 對InnoDB表級別加LOCK_IS鎖，防止表結構變更操作
- 對查詢得到的記錄加LOCK_S共享鎖，這意味著在該隔離級別下，讀操作不會互相阻塞。而數據變更操作通常會對記錄加LOCK_X鎖，和LOCK_S鎖相衝突，InnoDB通過給查詢加記錄鎖的方式來保證了序列化的隔離級別。

注意不同的隔離級別下，數據具有不同的隔離性，甚至事務鎖的加鎖策略也不盡相同，你需要根據自己實際的業務情況來進行選擇。

一個有趣的可見性問題

在READ-COMMITTED隔離級別下，我們考慮如下執行序列

Session 1：
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT, c3 INT, key(c2));
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t1 VALUES (1,2,3);
Query OK, 1 row affected (0.00 sec)

Session 2:
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE t1 SET c3=c3+1 WHERE c3 = 3;    // 掃描聚集索引進行查詢，記錄不可見，但未被記錄鎖堵塞
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> UPDATE t1 SET c3=c3+1 WHERE c2 = 2;   // 根據二級索引進行查詢，記錄不可見，且被記錄鎖堵塞

查詢條件不同，但指向的確是同一條已插入未提交的記錄，為什麼會有兩種不同的表現呢？這主要是不同索引在數據檢索時的策略不同造成的。

實際上session2的第一條Update也為session1做了隱式鎖轉換，但是在返回到row_search_mvcc時，會走到如下判斷：

Line 5312~5318,  row0sel.cc:
                        if (UNIV_LIKELY(prebuilt->row_read_type
                                        != ROW_READ_TRY_SEMI_CONSISTENT)
                            || unique_search
                            || index != clust_index) {

                                goto lock_wait_or_error;
                        }

對於第一條和第二條update， prebuilt->row_read_type值均為ROW_READ_TRY_SEMI_CONSISTENT，不滿足第一個條件；
均不滿足unique_search(通過pk，或uk作為where條件進行查詢)
第一個使用的聚集索引，三個條件都不滿足；而第二個update使用的二級索引，因此走lock_wait_or_error的邏輯，進入鎖等待。

第一條update繼續往下走，根據undo去構建老版本記錄（row_sel_build_committed_vers_for_mysql），一條新插入的記錄老版本就是空了，所以認為這條更新沒有查詢到目標記錄，從而忽略了鎖阻塞的邏輯。

如果使用pk或者二級索引作為where條件查詢的話，都會走到鎖等待條件。

推而廣之，如果表上沒有索引的話，那麼對於任意插入的記錄，更新操作都見不到插入的記錄（但是會為插入操作創建記錄鎖）。

InnoDB ACID

本小節針對ACID這四種數據庫特性分別進行簡單描述。

Atomicity （原子性）

所謂原子性，就是一個事務要麼全部完成變更，要麼全部失敗。如果在執行過程中失敗，回滾操作需要保證“好像”數據庫從沒執行過這個事務一樣。

從用戶的角度來看，用戶發起一個COMMIT語句，要保證事務肯定成功完成了；若發起ROLLBACK語句，則幹淨的回滾掉事務所有的變更。
從內部實現的角度看，InnoDB對事務過程中的數據變更總是維持了undo log，若用戶想要回滾事務，能夠通過Undo追溯最老版本的方式，將數據全部回滾回來。若用戶需要提交事務，則將提交日誌刷到磁盤。

Consistency （一致性）

一致性指的是數據庫需要總是保持一致的狀態，即使實例崩潰了，也要能保證數據的一致性，包括內部數據存儲的準確性，數據結構（例如btree）不被破壞。InnoDB通過doublewrite buffer 和crash recovery實現了這一點：前者保證數據頁的準確性，後者保證恢複時能夠將所有的變更apply到數據頁上。如果崩潰恢複時存在還未提交的事務，那麼根據XA規則提交或者回滾事務。最終實例總能處於一致的狀態。

另外一種一致性指的是數據之間的約束不應該被事務所改變，例如外鍵約束。ySQL支持自動檢查外鍵約束，或是做級聯操作來保證數據完整性，但另外也提供了選項foreign_key_checks，如果您開啟了這個選項，數據間的約束和一致性就會失效。有些情況下，數據的一致性還需要用戶的業務邏輯來保證。

Isolation （隔離性）

隔離性是指多個事務不可以對相同數據同時做修改，事務查看的數據要麼就是修改之前的數據，要麼就是修改之後的數據。InnoDB支持四種隔離級別，如上文所述，這裏不再重複。

Durability（持久性）

當一個事務完成了，它所做的變更應該持久化到磁盤上，永不丟失。這個特性除了和數據庫係統相關外，還和你的硬件條件相關。 InnoDB給出了許多選項，你可以為了追求性能而弱化持久性，也可以為了完全的持久性而弱化性能。

和大多數DBMS一樣，InnoDB也遵循WAL（Write-Ahead Logging）的原則，在寫數據文件前，總是保證日誌已經寫到了磁盤上。通過Redo日誌可以恢複出所有的數據頁變更。

為了保證數據的正確性，Redo log和數據頁都做了checksum校驗，防止使用損壞的數據。目前5.7版本默認支持使用CRC32的數據校驗算法。

為了解決半寫的問題，即寫一半數據頁時實例crash，這時候數據頁是損壞的。InnoDB使用double write buffer來解決這個問題，在寫數據頁到用戶表空間之前，總是先持久化到double write buffer，這樣即使沒有完整寫頁，我們也可以從double write buffer中將其恢複出來。你可以通過innodb_doublewrite選項來開啟或者關閉該特性。

InnoDB通過這種機製保證了數據和日誌的準確性的。你可以將實例配置成事務提交時將redo日誌fsync到磁盤（innodb_flush_log_at_trx_commit = 1），數據文件的FLUSH策略（innodb_flush_method）修改為0_DIRECT，以此來保證強持久化。你也可以選擇更弱化的配置來保證實例的性能。

最後更新：2017-04-01 13:44:35