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;elsetc_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中）。
如下圖所示：
總共分為以下幾步：
回滾SAVEPOINT
語法： ROLLBACK TO [ SAVEPOINT ] sp_name
入口函數：trans_rollback_to_savepoint
檢查點的回滾主要包括：
根據之前記錄的undo_no，可以逆向操作當前事務占用的undo slot上的undo記錄來進行回滾。
- 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）
首先判斷記錄對應的事務ID是否還處于活躍狀態
聚集索引： `lock_clust_rec_some_has_impl`二級索引： `lock_sec_rec_some_has_impl`如果不活躍，說明事務已提交，我們可以對這條記錄做任何更改操作。直接返回
否則返回獲取的trx_id
上述流程中長時間持有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的保護下進行，相當于拿到了當時的一個全局事務快照?；谏鲜鲎兞?#xff0c;我們就可以判斷數據頁上的記錄是否對當前事務可見了。
為了管理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日志中?；貪L段指針包括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: 0mysql> 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，以此來保證強持久化。你也可以選擇更弱化的配置來保證實例的性能。
總結
以上是生活随笔為你收集整理的MySQL · 引擎特性 · InnoDB 事务子系统介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PHP性能如何实现全面优化？
- 下一篇： Java API —— Map接口