MySQL · 引擎特性 · InnoDB 事务子系统介绍
前言
在前面幾期關(guān)于InnoDB Redo和Undo實現(xiàn)的鋪墊后，本節(jié)我們從上層的角度來闡述InnoDB的事務(wù)子系統(tǒng)是如何實現(xiàn)的，涉及的內(nèi)容包括：InnoDB的事務(wù)相關(guān)模塊，如何實現(xiàn)MVCC及ACID，如何進行事務(wù)的并發(fā)控制，事務(wù)系統(tǒng)如何進行管理等相關(guān)知識。本文的目的是讓讀者對事務(wù)系統(tǒng)有一個較全面的理解。
由于不同版本對事務(wù)系統(tǒng)都有改變，本文的所有分析基于當前GA的最新版本MySQL5.7.9，但也會在闡述的過程中，順帶描述之前版本的一些內(nèi)容。本文也會介紹5.7版本對事務(wù)系統(tǒng)的一些優(yōu)化點。
另外盡管InnoDB鎖系統(tǒng)和事務(wù)有著非常密切的聯(lián)系，但鑒于本文主要介紹事務(wù)模塊，并且計劃中的篇幅已經(jīng)足夠長。而鎖系統(tǒng)又是一個非常復雜的模塊，將在后面的月報中單獨開一篇文章來講述。
在閱讀本文之前，強烈建議先閱讀下之前兩節(jié)的內(nèi)容，因為事務(wù)系統(tǒng)和這些模塊有著非常緊密的聯(lián)系：
MySQL · 引擎特性 · InnoDB undo log 漫游
MySQL · 引擎特性 · InnoDB redo log漫游
MySQL · 引擎特性 · InnoDB 崩潰恢復過程
開啟事務(wù)
InnoDB提供了多種方式來開啟一個事務(wù)，最簡單的就是以一條BEGIN語句開始，也可以以START TRANSACTION開啟事務(wù)，你還可以選擇開啟一個只讀事務(wù)還是讀寫事務(wù)。所有顯式開啟事務(wù)的行為都會隱式的將上一條事務(wù)提交掉。
所有顯示開啟事務(wù)的入口函數(shù)均為trans_begin，如下列出了幾種常用的事務(wù)開啟方式。
BEGIN
當以BEGIN開啟一個事務(wù)時，首先會去檢查是否有活躍的事務(wù)還未提交，如果沒有提交，則調(diào)用ha_commit_trans提交之前的事務(wù)。并釋放之前事務(wù)持有的MDL鎖。
執(zhí)行BEGIN命令并不會真的去引擎層開啟一個事務(wù)，僅僅是為當前線程設(shè)定標記，表示為顯式開啟的事務(wù)。
和BEGIN等效的命令還有“BEGIN WORK”及“START TRANSACTION”
START TRANSACTION READ ONLY
使用該選項開啟一個只讀事務(wù)，當以這種形式開啟事務(wù)時，會為當前線程的thd->tx_read_only設(shè)置為true。當Server層接受到任何數(shù)據(jù)更改的SQL時，都會直接拒絕請求，返回錯誤碼ER_CANT_EXECUTE_IN_READ_ONLY_TRANSACTION，不會進入引擎層。
這個選項可以強約束一個事務(wù)為只讀的，而只讀事務(wù)在引擎層可以走優(yōu)化過的邏輯，相比讀寫事務(wù)的開銷更小，例如不用分配事務(wù)id，不用分配回滾段，不用維護到全局事務(wù)鏈表中。
該事務(wù)開啟的方式從5.6版本開始引入。我們知道，在MySQL5.6版本中引入的一個對事務(wù)模塊的重要優(yōu)化：將全局事務(wù)鏈表拆成了兩個鏈表：一個用于維護只讀事務(wù)，一個用于維護讀寫事務(wù)。這樣我們在構(gòu)建一個一致性視圖時，只需要遍歷讀寫事務(wù)鏈表即可。但是在5.6版本中，InnoDB并不具備事務(wù)從只讀模式自動轉(zhuǎn)換成讀寫事務(wù)的能力，因此需要用戶顯式的使用以下兩種方式來開啟只讀事務(wù)：
- 執(zhí)行START TRANSACTION READ ONLY
- 或者將變量tx_read_only設(shè)置為true
5.7版本引入了模式自動轉(zhuǎn)換的功能，但該語法依然保留了。
另外一個有趣的點是，在5.7版本中，你可以通過設(shè)置session_track_transaction_info變量來跟蹤事務(wù)的狀態(tài)，這貨主要用于官方的分布式套件(例如fabric)，例如在一個負載均衡系統(tǒng)中，你需要知道哪些statement開啟或處于一個事務(wù)中，哪些statement允許連接分配器調(diào)度到另外一個connection。。只讀事務(wù)是一種特殊的事務(wù)狀態(tài)，因此也需要記錄到線程的Transaction_state_tracker中。
關(guān)于Session tracker，可以參閱官方WL#6631
START TRANSACTION READ WRITE
和上述相反，該SQL用于開啟讀寫事務(wù)。這也是默認的事務(wù)模式。但有一點不同的是，如果當前實例的read_only打開了且當前連接不是超級賬戶，則顯示開啟讀寫事務(wù)會報錯。
同樣的事務(wù)狀態(tài)TX_READ_WRITE也要加入到Session Tracker中。 另外包括上述幾種顯式開啟的事務(wù)，其標記TX_EXPLICIT也加入到session tracker中。
讀寫事務(wù)并不意味著一定在引擎層就被認定為讀寫事務(wù)了，5.7版本InnoDB里總是默認一個事務(wù)開啟時的狀態(tài)為只讀的。舉個簡單的例子，如果你事務(wù)的第一條SQL是只讀查詢，那么在InnoDB層，它的事務(wù)狀態(tài)就是只讀的，如果第二條SQL是更新操作，就將事務(wù)轉(zhuǎn)換成讀寫模式。
START TRANSACTION WITH CONSISTENT SNAPSHOT
和上面幾種方式不同的是，在開啟事務(wù)時還會順便創(chuàng)建一個視圖（Read View），在InnoDB中，視圖用于描述一個事務(wù)的可見性范圍，也是多版本特性的重要組成部分。
這里會進入InnoDB層，調(diào)用函數(shù)innobase_start_trx_and_assign_read_view，注意只有你的隔離級別設(shè)置成REPEATABLE READ（可重復讀）時，才會顯式開啟一個Read View，否則會拋出一個warning。
使用這種方式開啟事務(wù)時，事務(wù)狀態(tài)已經(jīng)被設(shè)置成ACTIVE的。
狀態(tài)變量TX_WITH_SNAPSHOT會加入到Session Tracker中。
AUTOCOMMIT = 0
當autocommit設(shè)置成0時，就無需顯式開啟事務(wù)，如果你執(zhí)行多條SQL但不顯式的調(diào)用COMMIT（或者執(zhí)行會引起隱式提交的SQL）進行提交，事務(wù)將一直存在。通常我們不建議將該變量設(shè)置成0，因為很容易由于程序邏輯或使用習慣造成事務(wù)長時間不提交。而事務(wù)長時間不提交，在MySQL里簡直就是噩夢，各種詭異的問題都會紛紛出現(xiàn)。一種典型的場景就是，你開啟了一條查詢，但由于未提交，導致后續(xù)對該表的DDL堵塞住，進而導致隨后的所有SQL全部堵塞，簡直就是災(zāi)難性的后果。
另外一種情況是，如果你長時間不提交一個已經(jīng)構(gòu)建Read View的事務(wù)，purge線程就無法清理一些已經(jīng)提交的事務(wù)鎖產(chǎn)生的undo日志，進而導致undo空間膨脹。具體的表現(xiàn)為ibdata文件瘋狂膨脹。我們曾在線上觀察到好幾百G的Ibdata文件。
TIPS：所幸的是從5.7版本開始提供了可以在線truncate undo log的功能，前提是開啟了獨立的undo表空間，并保留了足夠的undo回滾段配置（默認128個），至少需要35個回滾段。其truncate原理也比較簡單：當purge線程發(fā)現(xiàn)一個undo文件超過某個定義的閥值時，如果沒有活躍事務(wù)引用這個undo文件，就將其設(shè)置成不可分配，并直接物理truncate文件。
提交事務(wù)
事務(wù)的提交分為兩種方式，一種是隱式提交，一種是顯式提交。
當你顯式開啟一個新的事務(wù)，或者執(zhí)行一條非臨時表的DDL語句時，就會隱式的將上一個事務(wù)提交掉。另外一種就是顯式的執(zhí)行“COMMIT” 語句來提交事務(wù)
然而， 在不同的場景下，MySQL在提交時進行的動作并不相同，這主要是因為MySQL是一種服務(wù)器層-引擎層的架構(gòu)，并存在兩套日志系統(tǒng)：Binary log及引擎事務(wù)日志。MySQL支持兩種XA事務(wù)方式：隱式XA和顯式XA；當然如果關(guān)閉binlog，并且僅使用一種事務(wù)引擎，就沒有XA可言了。
關(guān)于隱式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，且使用了事務(wù)引擎，則XA控制對象為mysql_bin_log
- 若關(guān)閉了binlog，且存在不止一種事務(wù)引擎時，則XA控制對象為tc_log_mmap
- 其他情況，使用tc_log_dummy，這種場景下就沒有什么XA可言了，無需任何協(xié)調(diào)者來進行XA。
這三者是TC_LOG的子類，關(guān)系如下圖所示：
具體的，包含以下幾種類型的XA（不對數(shù)據(jù)產(chǎn)生變更的只讀事務(wù)無需走XA）
Binlog/Engine XA
當開啟binlog時, MySQL默認使用該隱式XA模式。 在5.7版本中，事務(wù)的提交流程包括：
- Binlog Prepare：
設(shè)置thd->durability_property= HA_IGNORE_DURABILITY, 表示在innodb prepare時，不刷redo log
- InnoDB Prepare （入口函數(shù)innobase_xa_prepare --> trx_prepare）：
更新InnoDB的undo回滾段，將其設(shè)置為Prepare狀態(tài)（TRX_UNDO_PREPARED）
- 進入組提交(ordered_commit)
Flush Stage： 此時形成的一組隊列，有l(wèi)eader依次為別的線程寫binlog文件
在準備寫binlog前，會調(diào)用ha_flush_logs接口，將存儲的日志寫到最新的LSN，然后再寫binlog到文件。這樣做的目的是為了提升組提交的效率，具體參閱之我寫的一篇月報
Sync Stage： 如果sync_binlog計數(shù)超過配置值，則進行一次文件fsync，注意，參數(shù)sync_binlog的含義不是指的這么多個事務(wù)之后做一次fsync，而是這么多“組”事務(wù)隊列后做一次fsync。
Semisync Stage (RDS MySQL only)：如果我們在事務(wù)commit之前等待備庫ACK（設(shè)置成AFTER_SYNC模式），用戶線程會釋放上一個stage的鎖，并等待ACk。這意味著在等待ACK的過程中，我們并不堵塞上一個stage的binlog寫入，可以增加一定的吞吐量。
Commit Stage：隊列中的事務(wù)依次進行innodb commit，將undo頭的狀態(tài)修改為TRX_UNDO_CACHED/TRX_UNDO_TO_FREE/TRX_UNDO_TO_PURGE任意一種 (undo相關(guān)知識參閱之前的月報)；并釋放事務(wù)鎖，清理讀寫事務(wù)鏈表、readview等一系列操作。每個事務(wù)在commit階段也會去更新事務(wù)頁的binlog位點。
TIPS：如果你關(guān)閉了binlog_order_commits選項，那么事務(wù)就各自進行提交，這種情況下不能保證innodb commit順序和binlog寫入順序一致，這不會影響到數(shù)據(jù)一致性，在高并發(fā)場景下還能提升一定的吞吐量。但可能影響到物理備份的數(shù)據(jù)一致性，例如使用xtrabackup（而不是基于其上的innobackup腳本）依賴于事務(wù)頁上記錄的binlog位點，如果位點發(fā)生亂序，就會導致備份的數(shù)據(jù)不一致。
Engine/Engine XA
當binlog關(guān)閉時，如果事務(wù)跨引擎了，就可以在事務(wù)引擎間進行XA了，典型的例如InnoDB和Tokudb（在RDS MySQL里已同時支持這兩種事務(wù)引擎）。當支持超過1種事務(wù)引擎時，并且binlog關(guān)閉了，就走TC LOG MMAP邏輯。對應(yīng)的XA控制對象為tc_log_mmap。
由于需要持久化事務(wù)信息以用于重啟恢復，因此在該場景下，tc_log_mmap模塊會創(chuàng)建一個文件，名為tc.log，文件初始化大小為24KB，使用mmap的方式映射到內(nèi)存中。
tc.log 以PAGE來進行劃分，每個PAGE大小為8K，至少需要3個PAGE，初始化的文件大小也為3個PAGE（TC_LOG_MIN_SIZE），每個Page對應(yīng)的結(jié)構(gòu)體對象為st_page，因此需要根據(jù)page數(shù)，完成文件對應(yīng)的內(nèi)存控制對象的初始化。初始化第一個page的header，寫入magic number以及當前的2PC引擎數(shù)（也就是total_ha_2pc）
下圖描述了tc.log的文件結(jié)構(gòu)：
在事務(wù)執(zhí)行的過程中，例如遇到第一條數(shù)據(jù)變更SQL時，會注冊一個唯一標識的XID（實際上通過當前查詢的query_id來唯一標識），之后直到事務(wù)提交，這個xid都不會改變。事務(wù)引擎本身在使用undo時，必須加上這個XID標識。
在進行事務(wù)Prepare階段，若事務(wù)涉及到多個引擎，先在各自引擎里做事務(wù)Prepare。
然后進入commit階段，這時候會將xid記錄到tc.log中（如上圖所示），這類涉及到相對復雜的page選擇流程，這里不展開描述，具體的參閱函數(shù)TC_LOG_MMAP::commit
在完成記錄到tc.log后，就到引擎層各自提交事務(wù)。這樣即使在引擎提交時失敗，我們也可以在crash recovery時，通過讀取tc.log記錄的xid，指導引擎層相符合xid的事務(wù)進行提交。
Engine Commit
當關(guān)閉binlog時，且事務(wù)只使用了一個事務(wù)引擎時，就無需進行XA了，相應(yīng)的事務(wù)commit的流程也有所不同。
首先事務(wù)無需進入Prepare狀態(tài)，因為對單引擎事務(wù)做XA沒有任何意義。
其次，因為沒有Prepare狀態(tài)的保護，事務(wù)在commit時需要對事務(wù)日志進行持久化。這樣才能保證所有成功返回的事務(wù)變更， 能夠在崩潰恢復時全部完成。
顯式XA
MySQL支持顯式的開啟一個帶命名的XA事務(wù)，例如：
XA BEGIN "xidname"do something..... XA END 'xidname' XA PREPARE 'xidname' // 當完成這一步時，如果崩潰恢復，是可以在啟動后通過XA RECOVER獲得事務(wù)信息，并進行顯式提交。 XA COMMIT 'xidname' // 完全提交事務(wù)一個有趣的問題是，在5.7之前的版本中，如果執(zhí)行XA的過程中，在完成XA PREPARE后，如果kill掉session，事務(wù)就丟失了，而不是像崩潰恢復那樣，可以直接恢復出來。這主要是因為MySQL對Kill session的行為處理是直接回滾事務(wù)。
為了解決這個問題，MySQL5.7版本做了不小的改動，將XA的兩階段都記錄到了binlog中。 這樣狀態(tài)是持久化了的，一次干凈的shutdown后，可以通過掃描binlog恢復出XA事務(wù)的狀態(tài)，對于kill session導致的XA事務(wù)丟失，邏輯則比較簡單：內(nèi)存中使用一個transaction_cache維護了所有的XA事務(wù)，在斷開連接調(diào)用THD::cleanup時不做回滾，僅設(shè)置事務(wù)標記即可。
具體的參閱我之前寫的這篇月報
事務(wù)回滾
當由于各種原因（例如死鎖，或者顯式ROLLBACK）需要將事務(wù)回滾時，會調(diào)用handler接口ha_rollback_low，進而調(diào)用InnoDB函數(shù)trx_rollback_for_mysql來回滾事務(wù)。 回滾的方式是提取undo日志，做逆向操作。
由于InnoDB的undo是單獨寫在表空間中的，本質(zhì)上和普通的數(shù)據(jù)頁是一樣的。如果在事務(wù)回滾時，undo頁已經(jīng)被從內(nèi)存淘汰，回滾操作（特別是大事務(wù)變更回滾）就可能伴隨大量的磁盤IO。因此InnoDB的回滾效率非常低。有的數(shù)據(jù)庫管理系統(tǒng)，例如PostgreSQL，通過在數(shù)據(jù)頁上冗余數(shù)據(jù)產(chǎn)生版本鏈的方式來實現(xiàn)多版本，因此回滾起來非常方便，只需要設(shè)置標記即可，但額外帶來的問題就是無效數(shù)據(jù)清理開銷。
SavePoint管理
在事務(wù)執(zhí)行的過程中，你可以通過設(shè)置SAVEPOINT的方式來管理事務(wù)的執(zhí)行過程。
在介紹Savepoint之前，需要先介紹下trx_t::undo_no。在事務(wù)每次成功寫入一次undo后，這個計數(shù)都會遞增一次（參閱函數(shù)trx_undo_report_row_operation）。事務(wù)的undo_no也會記錄到undo page中進行持久化。因此在undo鏈表上的undo_no總是有序遞增的。
總的來說，主要有以下幾種操作類型。
設(shè)置SAVEPOINT
語法： SAVEPOINT sp_name
入口函數(shù)：trans_savepoint
在事務(wù)中設(shè)置一個SAVEPOINT，你可以隨意命名一個名字，在事務(wù)中設(shè)置的所有savepoint實際上維護了兩份鏈表，一份掛在THD變量上（thd->get_transaction()->m_savepoints），包含了基本的savepoint信息及到引擎層的映射，另一份在引擎層的事務(wù)對象上（維持鏈表trx_t::trx_savepoints中）。
如下圖所示：
總共分為以下幾步：
回滾SAVEPOINT
語法： ROLLBACK TO [ SAVEPOINT ] sp_name
入口函數(shù)：trans_rollback_to_savepoint
檢查點的回滾主要包括：
根據(jù)之前記錄的undo_no，可以逆向操作當前事務(wù)占用的undo slot上的undo記錄來進行回滾。
- binlog關(guān)閉的情況下，總是允許回滾MDL鎖
-
或者由引擎來確認（ha_rollback_to_savepoint_can_release_mdl），同時滿足：
- InnoDB：如果當前事務(wù)不持有任何事務(wù)鎖（表級或者行級），則認為可以回滾MDL鎖。
- Binlog：如果沒有更改非事務(wù)引擎，則可以釋放MDL鎖。
如果允許回滾MDL，則通過之前記錄的st_savepoint::mdl_savepoint進行回滾
釋放SAVEPOINT
語法為： RELEASE SAVEPOINT sp_name
入口函數(shù)：trans_rollback_to_savepoint
顧名思義，就是刪除一個SAVEPOINT，操作也很簡單，直接根據(jù)命名從server層和innodb層的清理掉，并釋放對應(yīng)的內(nèi)存。
隱式SAVEPOINT
在InnoDB中，還有一種隱式的savepoint，通過變量trx_t::last_sql_stat_start來維護。
初始狀態(tài)下trx_t::last_sql_stat_start的值為0，當執(zhí)行完一條SQL時，會調(diào)用函數(shù)trx_mark_sql_stat_end將當前的trx_t::undo_no保存到trx_t::last_sql_stat_start中。
如果SQL執(zhí)行失敗，就可以據(jù)此進行statement級別的回滾操作（trx_rollback_last_sql_stat_for_mysql）。
無論是顯式SAVEPOINT還是隱式SAVEPOINT，都是通過undo_no來指示回滾到哪個事務(wù)狀態(tài)。
兩個有趣的bug
bug#79493
在一個只讀事務(wù)中，如果設(shè)置了SAVEPOINT，任意執(zhí)行一次ROLLBACK TO SAVEPOINT都會將事務(wù)從只讀模式改變成讀寫模式。這主要是因為在活躍事務(wù)中執(zhí)行ROLLBACK 操作會強制轉(zhuǎn)換READ-WRITE模式。實際上這是沒必要的，因為并沒有造成任何的數(shù)據(jù)變更。
bug#79596
這個bug可以認為是一個相當嚴重的bug：在一個活躍的做過數(shù)據(jù)變更操作的事務(wù)中，任意執(zhí)行一次ROLLBACK TO SAVEPOINT（即使SAVEPOINT不存在），然后kill掉客戶端，會發(fā)現(xiàn)事務(wù)卻提交了，并且沒有寫到binlog中。這會導致主備的數(shù)據(jù)不一致。
重現(xiàn)步驟如下：
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時會導致事務(wù)commit。這主要是因為如果直接kill客戶端，服務(wù)器端在清理線程資源，進行事務(wù)回滾時，相關(guān)的變量并沒有被重設(shè)，thd的command類型還是SQLCOM_ROLLBACK_TO_SAVEPOINT，在函數(shù)MYSQL_BIN_LOG::rollback函數(shù)中將不會調(diào)用ha_rollback_low的引擎層回滾邏輯。 原因是回滾到某個savepoint有特殊的處理流程，
如果是通過ctrl+c的方式關(guān)閉client段，實際上會發(fā)送一個類型為COM_QUIT的command，它會將thd->lex->sql_command設(shè)置為SQLCOM_END，這時候會走正常的回滾邏輯。
事務(wù)執(zhí)行管理
在事務(wù)執(zhí)行的過程中，需要多個模塊來輔助事務(wù)的正常執(zhí)行：
- Server層的MDL鎖模塊，維持了一個事務(wù)過程中所有涉及到的表級鎖對象。通過MDL鎖，可以堵塞DDL，避免DDL和DML記錄binlog亂序；
- InnoDB的trx_sys子系統(tǒng)，維持了所有的事務(wù)狀態(tài)，包括活躍事務(wù)，非活躍事務(wù)對象，讀寫事務(wù)鏈表，負責分配事務(wù)id，回滾段，Readview等信息，是事務(wù)系統(tǒng)的總控模塊；
- InnoDB的lock_sys子系統(tǒng)，維護事務(wù)鎖信息，用于對修改數(shù)據(jù)操作做并發(fā)控制，保證了在一個事務(wù)中被修改的記錄，不可以被另外一個事務(wù)修改；
- InnoDB的log_sys子系統(tǒng)，負責事務(wù)redo日志管理模塊，
- InnoDB的purge_sys子系統(tǒng)，則主要用于在事務(wù)提交后，進行垃圾回收，以及數(shù)據(jù)頁的無效數(shù)據(jù)清理。
總的來說，事務(wù)管理模塊的架構(gòu)圖，如下圖所示：
下面就幾個事務(wù)模塊的關(guān)鍵點展開描述。
事務(wù)ID
在InnoDB一直維持了一個不斷遞增的整數(shù)，存儲在trx_sys->max_trx_id中；每次開啟一個新的讀寫事務(wù)時，都將該id分配給事務(wù)，同時遞增全局計數(shù)。事務(wù)id可以看做一個事務(wù)的唯一標識。
在MySQL5.6及之前的版本中，總是為事務(wù)分配ID。但實際上這是沒有必要的，畢竟只有做過數(shù)據(jù)更改的讀寫事務(wù)，我們才需要去根據(jù)事務(wù)id判斷可見性。因此在MySQL5.7版本中，只有讀寫事務(wù)才會分配事務(wù)id，只讀事務(wù)的id默認為0。
那么問題來了，怎么去區(qū)分不同的只讀事務(wù)呢 ？ 這里在需要輸出事務(wù)id時（例如執(zhí)行SHOW ENGINE INNODB STATUS 或者查詢INFORMATION_SCHEMA.INNODB_TRX表），使用只讀事務(wù)對象的指針或上一個常量來標識其唯一性，具體的計算方式見函數(shù)trx_get_id_for_print。 所以如果你show出來的事務(wù)id看起來數(shù)字特別龐大， 千萬不要驚訝。
對于全局最大事務(wù)id，每做256次賦值(TRX_SYS_TRX_ID_WRITE_MARGIN)就持久化一次到ibdata的事務(wù)頁(TRX_SYS_PAGE_NO)中。
已分配的事務(wù)Id會加入到全局讀寫事務(wù)Id集合中（trx_sys->rw_trx_ids），事務(wù)Id和事務(wù)對象的map加入到trx_sys->rw_trx_set中，這是個有序的集合(std::set)，可以用于通過trx id快速定位到對應(yīng)的事務(wù)對象。
事務(wù)分配得到的ID并不是立刻就被使用了，而是在做了數(shù)據(jù)修改時，需要創(chuàng)建或重用一個undo slot時，會將當前事務(wù)的id寫入到undo page頭，狀態(tài)為TRX_UNDO_ACTIVE。這也是崩潰恢復時，InnoDB判斷是否有未完成事務(wù)的重要依據(jù)。
在執(zhí)行數(shù)據(jù)更改的過程中，如果我們更新的是聚集索引記錄，事務(wù)ID + 回滾段指針會被寫到聚集索引記錄中，其他會話可以據(jù)此來判斷可見性以及是否要回溯undo鏈。
對于普通的二級索引頁更新, 則采用回溯聚集索引頁的方式來判斷可見性（如果需要的話）。關(guān)于MVCC，后文會有單獨描述。
事務(wù)鏈表和集合
事務(wù)子系統(tǒng)維護了三個不同的鏈表，用來管理事務(wù)對象
trx_sys->mysql_trx_list
包含了所有用戶線程的事務(wù)對象，即使是未開啟的事務(wù)對象，只要還沒被回收到trx_pool中，都被放在該鏈表上。當session斷開時，事務(wù)對象從鏈表上摘取，并被回收到trx_pool中，以待重用。
trx_sys->rw_trx_list
讀寫事務(wù)鏈表，當開啟一個讀寫事務(wù)，或者事務(wù)模式轉(zhuǎn)換成讀寫模式時，會將當前事務(wù)加入到讀寫事務(wù)鏈表中，鏈表上的事務(wù)是按照trx_t::id有序的；在事務(wù)提交階段將其從讀寫事務(wù)鏈表上移除。
trx_sys->serialisation_list
序列化事務(wù)鏈表，在事務(wù)提交階段，需要先將事務(wù)的undo狀態(tài)設(shè)置為完成，在這之前，獲得一個全局序列號trx->no，從trx_sys->max_trx_id中分配，并將當前事務(wù)加入到該鏈表中。隨后更新undo等一系列操作后，因此進入提交階段的事務(wù)并不是trx->id有序的，而是根據(jù)trx->no排序。當完成undo更新等操作后，再將事務(wù)對象同時從serialisation_list和rw_trx_list上移除。
這里需要說明下trx_t::no，這是個不太好理清的概念，從代碼邏輯來看，在創(chuàng)建readview時，會用到序列化鏈表，鏈表的第一個元素具有最小的trx_t::no，會賦值給ReadView::m_low_limit_no。purge線程據(jù)此創(chuàng)建的readview，只有小于該值的undo，才可以被purge掉。
總的來說，mysql_trx_list包含了rw_trx_list上的事務(wù)對象，rw_trx_list包含了serialisation_list上的事務(wù)對象。
事務(wù)ID集合有兩個：
trx_sys->rw_trx_ids
記錄了當前活躍的讀寫事務(wù)ID集合，主要用于構(gòu)建ReadView時快速拷貝一個快照
trx_sys->rw_trx_set
這是的映射集合，根據(jù)trx_id排序，用于通過trx_id快速獲得對應(yīng)的事務(wù)對象。一個主要的用途就是用于隱式鎖轉(zhuǎn)換，需要為記錄中的事務(wù)id所對應(yīng)的事務(wù)對象創(chuàng)建記錄鎖，通過該集合可以快速獲得事務(wù)對象
事務(wù)回滾段
對于普通的讀寫事務(wù)，總是為其指定一個回滾段（默認128個回滾段）。而對于只讀事務(wù)，如果使用到了InnoDB臨時表，則為其分配(1~32)號回滾段。（回滾段指定參閱函數(shù)trx_assign_rseg_low）
當為事務(wù)指定了回滾段后，后續(xù)在事務(wù)需要寫undo頁時，就從該回滾段上分別分配兩個slot，一個用于update_undo，一個用于insert_undo。分別處理的原因是事務(wù)提交后，update_undo需要purge線程來進行回收，而insert_undo則可以直接被重利用。
關(guān)于undo相關(guān)知識可以參閱之前的月報
事務(wù)引用計數(shù)
在介紹事務(wù)引用計數(shù)之前，我們首先要了解下什么是隱式鎖。所謂隱式鎖，其實并不是一個真正的事務(wù)鎖對象，可以理解為一個標記：對于聚集索引頁的更新，記錄本身天然帶事務(wù)id，對于二級索引頁，則在page上記錄最近一次更新的最大事務(wù)id，通過回表的方式判斷可見性。
由于事務(wù)鎖涉及到全局資源，創(chuàng)建鎖的開銷高昂，InnoDB對于新插入的記錄，在沒有沖突的情況下是不創(chuàng)建記錄鎖的。舉個例子，Session 1插入一條記錄，并保持未提交狀態(tài)。另外一個session想更新這條記錄，從數(shù)據(jù)頁上讀取到這條記錄后，發(fā)現(xiàn)對應(yīng)的事務(wù)id還處于活躍狀態(tài)，根據(jù)當前的并發(fā)規(guī)則，這個更新需要被阻塞住。因此第二個session需要為session 1創(chuàng)建一條記錄鎖，然后將自己放入等待隊列中。
在MySQL5.7版本之前，隱式鎖轉(zhuǎn)換的邏輯為（函數(shù)lock_rec_convert_impl_to_expl）
首先判斷記錄對應(yīng)的事務(wù)ID是否還處于活躍狀態(tài)
聚集索引： `lock_clust_rec_some_has_impl`二級索引： `lock_sec_rec_some_has_impl`如果不活躍，說明事務(wù)已提交，我們可以對這條記錄做任何更改操作。直接返回
否則返回獲取的trx_id
上述流程中長時間持有l(wèi)ock_sys->mutex，目的是防止在為其轉(zhuǎn)換隱式鎖為顯式鎖時事務(wù)被提交掉。尤其是在第三步，同時持有兩把大鎖去查找事務(wù)對象。在5.6官方版本中，這種查找操作還需要遍歷鏈表，開銷巨大，推高了臨界資源的競爭。
因此在5.7中引入事務(wù)計數(shù)trx_t::n_ref來輔助判斷，在隱式鎖轉(zhuǎn)換時，通過讀寫事務(wù)集合(rw_trx_set)快速獲得事務(wù)對象，同時對trx_t::n_def遞增。這個過程無需加lock_sys->mutex鎖。隨后再持有Lock_sys->mutex去創(chuàng)建顯式鎖。在完成創(chuàng)建后，遞減trx_t::n_ref。
為了防止為一個已提交的事務(wù)創(chuàng)建顯式鎖；在事務(wù)提交階段也做了處理：在事務(wù)釋放事務(wù)鎖之前，如果引用計數(shù)非0，則表示有人正在做隱式鎖轉(zhuǎn)換，這里需要等待其完成。(參考函數(shù)lock_trx_release_locks)。
實際上上述修改是在官方優(yōu)化讀寫事務(wù)鏈表之前完成的。由于在5.7里已經(jīng)使用一個有序的集合保存了trx_id到trx_t的關(guān)聯(lián)，可以非常快速的定位到事務(wù)對象，這個優(yōu)化帶來的性能提升已經(jīng)沒那么明顯了。
關(guān)于隱式鎖更詳細的信息，我們將在之后專門講述“事務(wù)鎖”的月報中再單獨描述。
事務(wù)并發(fā)控制
在MySQL5.7中，由于消除了大量臨界資源的競爭，InnoDB只讀查詢的性能非常優(yōu)化，幾乎可以隨著CPU線性擴展。但如果進入到讀寫混合的場景，就不可避免的使用到一些臨界資源，例如事務(wù)、鎖、日志等子系統(tǒng)。當競爭越激烈，就可能導致性能的下降。通常系統(tǒng)會有個吞吐量和響應(yīng)時間最優(yōu)的性能拐點。
InnoDB本身提供了并發(fā)控制機制，一種是語句級別的并發(fā)控制，另外一種是事務(wù)提交階段的并發(fā)控制。
語句級別的并發(fā)通過參數(shù)innodb_thread_concurrency來控制，表示允許同時在InnoDB層活躍的并發(fā)SQL數(shù)。
每條SQL在進入InnoDB層進行操作之前都需要先遞增全局計數(shù)，并為當前sql分配innodb_concurrency_tickets個ticket。也就是說，如果當前sql需要進出InnoDB層很多次（例如一個大查詢需要掃描很多行數(shù)據(jù)時），innodb_concurrency_tickets次都可以自由進入InnoDB，無需判斷innodb_thread_concurrency。當ticket用完時，就需要重新進入。當SQL執(zhí)行完成后，會將ticket重置為0。
如果當前InnoDB層的并發(fā)度已滿，用戶線程就需要等待，目前的實現(xiàn)使用sleep一段時間的方式，sleep的時間是自適應(yīng)的，但你可以通過參數(shù)innodb_adaptive_max_sleep_delay來設(shè)置一個最多大sleep事件，具體的算法參閱函數(shù)srv_conc_enter_innodb_with_atomics。
提到并發(fā)控制，另外一個不得不提的問題就是熱點更新問題。事務(wù)在進入InnoDB層，準備更新一條數(shù)據(jù)，但發(fā)現(xiàn)行記錄被其他線程鎖住，這時候該線程會強制退出innodb并發(fā)控制，同時將自己suspend住，進入睡眠等待。如果有大量并發(fā)的更新同一條記錄，就意味著大量線程進入InnoDB層，訪問熱點競爭資源鎖系統(tǒng)，然后再退出。最終會呈現(xiàn)出大量線程在innodb中suspend住，相當于并發(fā)控制并沒有達到降低臨界資源爭用的效果。早期我們對該問題的優(yōu)化就是將線程從堵在innodb層，轉(zhuǎn)移到堵在進入innodb層時的外部排隊中，這樣就不涉及到InnoDB的資源爭用了。具體的實現(xiàn)是將statement級別的并發(fā)控制提升為事務(wù)級別的并發(fā)控制，因此這個方案的缺陷是對長事務(wù)不友好。
另外還有一些并發(fā)控制方案，例如線程池、水位限流、按pk排隊等策略，我們的RDS MySQL也很早就支持了。如果你存在熱點爭用（例如秒殺場景），并且正在使用RDS MySQL，你可以去咨詢售后如何使用這些特性。
除了語句級別的并發(fā)外，InnoDB也提供了提交階段的并發(fā)控制，主要通過參數(shù)innodb_commit_concurrency來控制。該參數(shù)的默認值為0，表示不控制commit階段的并發(fā)。在進入函數(shù)innobase_commit時，如果該參數(shù)被設(shè)置，且當前并發(fā)度超過，就需要等待。然而由于當前在默認配置下所有事務(wù)都走組提交(ordered_commit)，innodb層的提交大多數(shù)情況下只會有一個活躍線程。你只有關(guān)閉binlog或者關(guān)閉參數(shù)binlog_order_commits，這個參數(shù)設(shè)置才有意義。
高優(yōu)先級事務(wù)
MySQL5.7 實現(xiàn)了一種高優(yōu)先級的事務(wù)調(diào)度方式。當事務(wù)處于高優(yōu)先級模式時，它將永遠不會被選作deadlock場景的犧牲者，擁有獲得鎖的最高優(yōu)先級，并能kill掉阻塞它的的優(yōu)先級事務(wù)。這個特性主要是為了支持官方開發(fā)的Group Replication Plugin套件，以保證事務(wù)總是能在所有的節(jié)點上提交。
如何使用
目前GA版本還沒有提供公共接口來使用該功能，但代碼實現(xiàn)都是完備的，如果想使用該功能，直接寫一個設(shè)置變量的接口即可，非常簡單。
在server層，每個THD上新增了兩個變量來標識事務(wù)的優(yōu)先級：
- THD::tx_priority 事務(wù)級別有效，當兩個事務(wù)在innodb層沖突時，擁有更高值的事務(wù)將贏得鎖
- THD::thd_tx_priority 線程級別有效，當該變量被設(shè)置時，選擇該值作為事務(wù)優(yōu)先級，否則選擇tx_priority
死鎖檢測
在進行死鎖檢測時，需要對死鎖的兩個事務(wù)的優(yōu)先級進行比較，低優(yōu)先級的總是會被優(yōu)先回滾掉，以保證高優(yōu)先級的事務(wù)正常執(zhí)行（DeadlockChecker::check_and_resolve）
處理鎖等待
在對記錄嘗試加鎖時，如果發(fā)現(xiàn)有別的事務(wù)和當前事務(wù)沖突（lock_re_other_has_conflicting），需要判斷是否要加入到等待隊列中（RecLock::add_to_wait）：
- 如果兩個事務(wù)都設(shè)置了高優(yōu)先級、但當前事務(wù)優(yōu)先級較低，或者沖突的事務(wù)是一個后臺進程開啟的事務(wù)（例如dict_stat線程進行統(tǒng)計信息更新），則立刻失敗該事務(wù)，并返回DB_DEADLOCK錯誤碼
- 嘗試將當前鎖對象加入到等待隊列中(RecLock::enqueue_priority)，高優(yōu)先級的事務(wù)可以跳過鎖等待隊列(RecLock::jump_queue)，被跳過的事務(wù)需要被標記為異步回滾狀態(tài)（RecLock::mark_trx_for_rollback），搜集到當前事務(wù)的trx_t::hit_list鏈表中。當阻塞當前事務(wù)的另外一個事務(wù)也處于等待狀態(tài)、但等待另外一個不同的記錄鎖時，調(diào)用rollback_blocking_trx直接回滾掉，否則在進入鎖等待之前再調(diào)用trx_kill_blocking依次回滾。
這里涉及到事務(wù)鎖模塊，本文不展開描述，下次專門在事務(wù)鎖相關(guān)主題的月報講述，你可以通過官方WL#6835 獲取更多關(guān)于高優(yōu)先級事務(wù)的信息
trx_t::flush_observer
閱讀代碼時發(fā)現(xiàn)這個在5.7版本新加的變量，從它的命名可以看出，其應(yīng)該和臟頁flush相關(guān)。flush_observer可以認為是一個標記，當某種操作完成時，對于帶這種標記的page(buf_page_t::flush_observer)，需要保證完全刷到磁盤上。
該變量主要解決早期5.7版本建索引耗時太久的bug#74472：為表增加索引的操作非常慢，即使表上沒幾條數(shù)據(jù)。原因是innodb在5.7版本修正了建索引的方式，采用自底向上的構(gòu)建方式，并在創(chuàng)建索引的過程中關(guān)閉了redo，因此在做完加索引操作后，必須將其產(chǎn)生的臟頁完全寫到磁盤中，才能認為索引構(gòu)建完畢，所以發(fā)起了一次完全的checkpoint，但如果buffer pool中存在大量臟頁時，將會非常耗時。
為了解決這一問題，引入了flush_observer，在建索引之前創(chuàng)建一個FlushObserver并分配給事務(wù)對象(trx_set_flush_observer)，同時傳遞給BtrBulk::m_flush_observer。
在構(gòu)建索引的過程中產(chǎn)生的臟頁，通過mtr_commit將臟頁轉(zhuǎn)移到flush_list上時，順便標記上flush_observer（add_dirty_page_to_flush_list —> buf_flush_note_modification）
當做完索引構(gòu)建操作后，由于bulk load操作不記redo，需要保證DDL產(chǎn)生的所有臟頁都寫到磁盤，因此調(diào)用FlushObserver::flush，將臟頁寫盤（buf_LRU_flush_or_remove_pages）。在做完這一步后，才開始apply online ddl過程中產(chǎn)生的row log(row_log_apply)。
如果DDL被中斷（例如session被kill），也需要調(diào)用FlushObserver::flush，將這些產(chǎn)生的臟頁從內(nèi)存移除掉，無需寫盤。
事務(wù)對象池
為了減少構(gòu)建事務(wù)對象時的內(nèi)存操作開銷，尤其是短連接場景下的性能，InnoDB引入了一個池結(jié)構(gòu)，可以很方便的分配和釋放事務(wù)對象。實際上事務(wù)的事務(wù)鎖對象也引用了池結(jié)構(gòu)。
事務(wù)池對應(yīng)的全局變量為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表示事務(wù)對象類型，TrxFactory封裝了事務(wù)的初始化和，TrxPoolLock封裝了POOL鎖的創(chuàng)建，銷毀，加鎖，解鎖。
PoolManager封裝了池的管理方法
這里涉及到多個類：
- Pool 及 PoolManager 是公共用的類
- TrxFactory 和 TrxPoolLock, TrxPoolManagerLock是trx pool私有的類。
- TrxFactory用于定義池中事務(wù)對象的初始化和銷毀動作；
- TrxPoolLock用于定義每個池中對象的互斥鎖操作；
- 由于POOL的管理結(jié)構(gòu)支持多個POOL對象， TrxPoolManagerLock用于互斥操作增加POOL對象。支持多個POOL對象的目的是分拆單個POOL對象的鎖開銷，避免引入熱點。因為從POOL中獲取和返還對象，都是需要排他鎖的。
相關(guān)類的關(guān)系如下圖所示：
InnoDB MVCC實現(xiàn)
InnoDB有兩個非常重要的模塊來實現(xiàn)MVCC，一個是undo日志，用于記錄數(shù)據(jù)的變化軌跡，另外一個是Readview，用于判斷該session對哪些數(shù)據(jù)可見，哪些不可見。實際上我們已經(jīng)在之前的月報中介紹過這部分內(nèi)容，這里再簡要介紹下。
事務(wù)視圖ReadView
前面已經(jīng)多次提到過ReadView，也就是事務(wù)視圖，它用于控制數(shù)據(jù)的可見性，在InnoDB中，只有查詢才需要通過Readview來控制可見性，對于DML等數(shù)據(jù)變更操作，如果操作了不可見的數(shù)據(jù)，則直接進入鎖等待。
ReadView包含幾個重要的變量：
- ReadView::id 創(chuàng)建該視圖的事務(wù)id
- ReadView::m_ids 創(chuàng)建readview時，活躍的讀寫事務(wù)id數(shù)組，有序存儲
- ReadView::m_low_limit_id 設(shè)置為當前最大事務(wù)id
- ReadView::m_up_limit_id m_ids集合中的最小值，如果m_ids集合為空，表示當前沒有活躍讀寫事務(wù)，則設(shè)置為當前最大事務(wù)id
很顯然ReadView的創(chuàng)建需要在trx_sys->mutex的保護下進行，相當于拿到了當時的一個全局事務(wù)快照。基于上述變量，我們就可以判斷數(shù)據(jù)頁上的記錄是否對當前事務(wù)可見了。
為了管理ReadView，MVCC子系統(tǒng)使用多個鏈表進行分配、維護、回收Readview
- MVCC::m_free 用于維護空閑的readview對象，初始化時創(chuàng)建1024個ReadView對象（trx_sys_create），當釋放一個活躍的視圖時，會將其加到該鏈表上，以便下次重用。
- MVCC::m_views 這里存儲了兩類視圖，一類是當前活躍的視圖，另一類是上次被關(guān)閉的只讀事務(wù)視圖。后者主要是為了減少視圖分配開銷。因為當系統(tǒng)的讀占大多數(shù)時，如果在兩次查詢中間沒有進行過任何讀寫操作，那我們就可以重用這個readview，而無需去持有trx_sys->mutex鎖重新分配。
目前自動提交的只讀事務(wù)或者RR級別下的只讀都支持read view緩存，但目前版本還存在的問題是，在RC級別下不支持視圖緩存，見bug#79005
另外purge系統(tǒng)在開始purge任務(wù)時，需去克隆MVCC::m_views鏈表上未被close的最老視圖，并在本地視圖中將該最老事務(wù)的事務(wù)id也加入到不可見的事務(wù)id集合ReadView::m_ids中(MVCC::clone_oldest_view)
回滾段指針
回滾段undo是實現(xiàn)InnoDB MVCC的根基。每次修改聚集索引頁上的記錄時，變更之前的記錄都會寫到undo日志中。回滾段指針包括undo log所在的回滾段id、日志所在的page no、以及page內(nèi)的偏移量，可以據(jù)此找到最近一次修改之前的undo記錄，而每條Undo記錄又能再次找到之前的變更。
當有可能undo被訪問到時，Purge_sys將不會去清理undo log，如上所述，purge_sys只會去清理最老readview不會看到的事務(wù)。這意味著，如果你運行了一個長時間的查詢SQL，或者以大于RC的隔離級別開啟了一個事務(wù)視圖但沒有提交事務(wù)，Purge系統(tǒng)將一直無法前行，即使你的會話并不活躍。這時候undo日志將無法被及時回收，最直觀的后果就是undo空間急劇膨脹。
關(guān)于undo這里不贅述，詳細參閱之前月報
可見性判斷
如上所述，聚集索引的可見性判斷和二級索引的可見性判斷略有不同。因為二級索引記錄并沒有存儲事務(wù)id信息，相應(yīng)的，只是在數(shù)據(jù)頁頭存儲了最近更新該page的trx_id。
對于聚集索引記錄，當我們從btree獲得一條記錄后，先判斷（lock_clust_rec_cons_read_sees）當前的readview是否滿足該記錄的可見性：
- 如果記錄的trx_id小于ReadView::m_up_limit_id，則說明該事務(wù)在創(chuàng)建readview時已經(jīng)提交了，肯定可見
- 如果記錄的trx_id大于等于ReadView::m_low_limit_id，則說明該事務(wù)是創(chuàng)建readview之后開啟的，肯定不可見。
- 當trx_id在m_up_limit_id和m_low_limit_id之間時，如果在ReadView::m_ids數(shù)組中，說明創(chuàng)建readview時該事務(wù)是活躍的，其做的變更對當前視圖不可見，否則對該trx_id的變更可見。
如果基于上述判斷，該數(shù)據(jù)變更不可見時，就嘗試通過undo去構(gòu)建老版本記錄（row_sel_build_prev_vers_for_mysql -->row_vers_build_for_consistent_read），直到找到可見的記錄，或者到達undo鏈表頭都未找到。
注意當隔離級別設(shè)置為READ UNCOMMITTED時，不會去構(gòu)建老版本。
如果我們查詢得到的是一條二級索引記錄：
- 首先將page頭的trx_id和當前視圖相比較：如果小于ReadView::m_up_limit_id，當前事務(wù)肯定可見；否則就需要去找到對應(yīng)的聚集索引記錄（lock_sec_rec_cons_read_sees）。
- 如果需要進一步判斷，先根據(jù)ICP條件，檢查是否該記錄滿足push down的條件，以減少回聚集索引的次數(shù)。
- 滿足ICP條件，則需要查詢聚集索引記錄（row_sel_get_clust_rec_for_mysql），之后的判斷就和上述聚集索引記錄的判斷一致了
在InnoDB中，只有讀查詢才會去構(gòu)建ReadView視圖，對于類似DML這樣的數(shù)據(jù)更改，無需判斷可見性，而是單純的發(fā)現(xiàn)事務(wù)鎖沖突，直接堵塞操作。
隔離級別
然而在不同的隔離級別下，可見性的判斷有很大的不同。
- READ-UNCOMMITTED
在該隔離級別下會讀到未提交事務(wù)所產(chǎn)生的數(shù)據(jù)更改，這意味著可以讀到臟數(shù)據(jù)，實際上你可以從函數(shù)row_search_mvcc中發(fā)現(xiàn)，當從btree讀到一條記錄后，如果隔離級別設(shè)置成READ-UNCOMMITTED，根本不會去檢查可見性或是查看老版本。這意味著，即使在同一條SQL中，也可能讀到不一致的數(shù)據(jù)。 - READ-COMMITTED
在該隔離級別下，可以在SQL級別做到一致性讀，當事務(wù)中的SQL執(zhí)行完成時，ReadView被立刻釋放了，在執(zhí)行下一條SQL時再重建ReadView。這意味著如果兩次查詢之間有別的事務(wù)提交了，是可以讀到不一致的數(shù)據(jù)的。 - REPEATABLE-READ
可重復讀和READ-COMMITTED的不同之處在于，當?shù)谝淮蝿?chuàng)建ReadView后（例如事務(wù)內(nèi)執(zhí)行的第一條SEELCT語句），這個視圖就會一直維持到事務(wù)結(jié)束。也就是說，在事務(wù)執(zhí)行期間的可見性判斷不會發(fā)生變化，從而實現(xiàn)了事務(wù)內(nèi)的可重復讀。 -
SERIALIZABLE
序列化的隔離是最高等級的隔離級別，當一個事務(wù)在對某個表做記錄變更操作時，另外一個查詢操作就會被該操作堵塞住。同樣的，如果某個只讀事務(wù)開啟并查詢了某些記錄，那么另外一個session對這些記錄的更改操作是被堵塞的。內(nèi)部的實現(xiàn)其實很簡單：- 對InnoDB表級別加LOCK_IS鎖，防止表結(jié)構(gòu)變更操作
- 對查詢得到的記錄加LOCK_S共享鎖，這意味著在該隔離級別下，讀操作不會互相阻塞。而數(shù)據(jù)變更操作通常會對記錄加LOCK_X鎖，和LOCK_S鎖相沖突，InnoDB通過給查詢加記錄鎖的方式來保證了序列化的隔離級別。
注意不同的隔離級別下，數(shù)據(jù)具有不同的隔離性，甚至事務(wù)鎖的加鎖策略也不盡相同，你需要根據(jù)自己實際的業(yè)務(wù)情況來進行選擇。
一個有趣的可見性問題
在READ-COMMITTED隔離級別下，我們考慮如下執(zhí)行序列
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; // 根據(jù)二級索引進行查詢，記錄不可見，且被記錄鎖堵塞查詢條件不同，但指向的確是同一條已插入未提交的記錄，為什么會有兩種不同的表現(xiàn)呢？ 這主要是不同索引在數(shù)據(jù)檢索時的策略不同造成的。
實際上session2的第一條Update也為session1做了隱式鎖轉(zhuǎn)換，但是在返回到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繼續(xù)往下走，根據(jù)undo去構(gòu)建老版本記錄（row_sel_build_committed_vers_for_mysql ），一條新插入的記錄老版本就是空了，所以認為這條更新沒有查詢到目標記錄，從而忽略了鎖阻塞的邏輯。
如果使用pk或者二級索引作為where條件查詢的話，都會走到鎖等待條件。
推而廣之，如果表上沒有索引的話，那么對于任意插入的記錄，更新操作都見不到插入的記錄（但是會為插入操作創(chuàng)建記錄鎖）。
InnoDB ACID
本小節(jié)針對ACID這四種數(shù)據(jù)庫特性分別進行簡單描述。
Atomicity （原子性）
所謂原子性，就是一個事務(wù)要么全部完成變更，要么全部失敗。如果在執(zhí)行過程中失敗，回滾操作需要保證“好像”數(shù)據(jù)庫從沒執(zhí)行過這個事務(wù)一樣。
從用戶的角度來看，用戶發(fā)起一個COMMIT語句，要保證事務(wù)肯定成功完成了；若發(fā)起ROLLBACK語句，則干凈的回滾掉事務(wù)所有的變更。
從內(nèi)部實現(xiàn)的角度看，InnoDB對事務(wù)過程中的數(shù)據(jù)變更總是維持了undo log，若用戶想要回滾事務(wù)，能夠通過Undo追溯最老版本的方式，將數(shù)據(jù)全部回滾回來。若用戶需要提交事務(wù)，則將提交日志刷到磁盤。
Consistency （一致性）
一致性指的是數(shù)據(jù)庫需要總是保持一致的狀態(tài)，即使實例崩潰了，也要能保證數(shù)據(jù)的一致性，包括內(nèi)部數(shù)據(jù)存儲的準確性，數(shù)據(jù)結(jié)構(gòu)（例如btree）不被破壞。InnoDB通過doublewrite buffer 和crash recovery實現(xiàn)了這一點：前者保證數(shù)據(jù)頁的準確性，后者保證恢復時能夠?qū)⑺械淖兏黙pply到數(shù)據(jù)頁上。如果崩潰恢復時存在還未提交的事務(wù)，那么根據(jù)XA規(guī)則提交或者回滾事務(wù)。 最終實例總能處于一致的狀態(tài)。
另外一種一致性指的是數(shù)據(jù)之間的約束不應(yīng)該被事務(wù)所改變，例如外鍵約束。ySQL支持自動檢查外鍵約束，或是做級聯(lián)操作來保證數(shù)據(jù)完整性，但另外也提供了選項foreign_key_checks，如果您開啟了這個選項，數(shù)據(jù)間的約束和一致性就會失效。有些情況下，數(shù)據(jù)的一致性還需要用戶的業(yè)務(wù)邏輯來保證。
Isolation （隔離性）
隔離性是指多個事務(wù)不可以對相同數(shù)據(jù)同時做修改，事務(wù)查看的數(shù)據(jù)要么就是修改之前的數(shù)據(jù)，要么就是修改之后的數(shù)據(jù)。InnoDB支持四種隔離級別，如上文所述，這里不再重復。
Durability（持久性）
當一個事務(wù)完成了，它所做的變更應(yīng)該持久化到磁盤上，永不丟失。這個特性除了和數(shù)據(jù)庫系統(tǒng)相關(guān)外，還和你的硬件條件相關(guān)。 InnoDB給出了許多選項，你可以為了追求性能而弱化持久性，也可以為了完全的持久性而弱化性能。
和大多數(shù)DBMS一樣，InnoDB也遵循WAL（Write-Ahead Logging）的原則，在寫數(shù)據(jù)文件前，總是保證日志已經(jīng)寫到了磁盤上。通過Redo日志可以恢復出所有的數(shù)據(jù)頁變更。
為了保證數(shù)據(jù)的正確性，Redo log和數(shù)據(jù)頁都做了checksum校驗，防止使用損壞的數(shù)據(jù)。目前5.7版本默認支持使用CRC32的數(shù)據(jù)校驗算法。
為了解決半寫的問題， 即寫一半數(shù)據(jù)頁時實例crash，這時候數(shù)據(jù)頁是損壞的。InnoDB使用double write buffer來解決這個問題，在寫數(shù)據(jù)頁到用戶表空間之前，總是先持久化到double write buffer，這樣即使沒有完整寫頁，我們也可以從double write buffer中將其恢復出來。你可以通過innodb_doublewrite選項來開啟或者關(guān)閉該特性。
InnoDB通過這種機制保證了數(shù)據(jù)和日志的準確性的。你可以將實例配置成事務(wù)提交時將redo日志fsync到磁盤（innodb_flush_log_at_trx_commit = 1），數(shù)據(jù)文件的FLUSH策略（innodb_flush_method）修改為0_DIRECT，以此來保證強持久化。你也可以選擇更弱化的配置來保證實例的性能。
總結(jié)
以上是生活随笔為你收集整理的MySQL · 引擎特性 · InnoDB 事务子系统介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PHP性能如何实现全面优化？
- 下一篇： mysql replication错误常