## 前言 在前面幾期關于 InnoDB Redo 和 Undo 實現的鋪墊后，本節我們從上層的角度來闡述 InnoDB 的事務子系統是如何實現的，涉及的內容包括：InnoDB的事務相關模塊、如何實現MVCC及ACID、如何進行事務的并發控制、事務系統如何進行管理等相關知識。本文的目的是讓讀者對事務系統有一個較全面的理解。 由于不同版本對事務系統都有改變，本文的所有分析基于當前GA的最新版本MySQL5.7.9，但也會在闡述的過程中，順帶描述之前版本的一些內容。本文也會介紹5.7版本對事務系統的一些優化點。 另外盡管 InnoDB 鎖系統和事務有著非常密切的聯系，但鑒于本文主要介紹事務模塊，并且計劃中的篇幅已經足夠長。而鎖系統又是一個非常復雜的模塊，將在后面的月報中單獨開一篇文章來講述。 在閱讀本文之前，強烈建議先閱讀下之前兩節的內容，因為事務系統和這些模塊有著非常緊密的聯系： [MySQL · 引擎特性 · InnoDB undo log 漫游](http://mysql.taobao.org/monthly/2015/04/01/) [MySQL · 引擎特性 · InnoDB redo log漫游](http://mysql.taobao.org/monthly/2015/05/01/) [MySQL · 引擎特性 · InnoDB 崩潰恢復過程](http://mysql.taobao.org/monthly/2015/06/01/) ## 事務開啟 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并不具備事務從只讀模式自動轉換成讀寫事務的能力，因此需要用戶顯式的使用以下兩種方式來開啟只讀事務： 1. 執行START TRANSACTION READ ONLY 2. 或者將變量`tx_read_only`設置為true 5.7版本引入了模式自動轉換的功能，但該語法依然保留了。 另外一個有趣的點是，在5.7版本中，你可以通過設置`session_track_transaction_info`變量來跟蹤事務的狀態，這貨主要用于官方的分布式套件(例如fabric)，例如在一個負載均衡系統中，你需要知道哪些 statement 開啟或處于一個事務中，哪些 statement 允許連接分配器調度到另外一個 connection。只讀事務是一種特殊的事務狀態，因此也需要記錄到線程的`Transaction_state_tracker`中。 關于Session tracker，可以參閱官方[WL#6631](http://dev.mysql.com/worklog/task/?id=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`的子類，關系如下圖所示：  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`) 1. Flush Stage：此時形成一組隊列，由leader依次為別的線程寫binlog文件 在準備寫binlog前，會調用`ha_flush_logs`接口，將存儲的日志寫到最新的LSN，然后再寫binlog到文件。這樣做的目的是為了提升組提交的效率，具體參閱之前的[一篇月報](http://mysql.taobao.org/index.php?title=MySQL%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A5_2015.01#MySQL_.C2.B7_.E6.80.A7.E8.83.BD.E4.BC.98.E5.8C.96.C2.B7_Group_Commit.E4.BC.98.E5.8C.96)。 2. Sync Stage：如果`sync_binlog`計數超過配置值，則進行一次文件fsync，注意，參數`sync_binlog`的含義不是指的這么多個事務之后做一次fsync，而是這么多組事務隊列后做一次fsync。 3. Semisync Stage (RDS MySQL only)：如果我們在事務commit之前等待備庫ACK（設置成AFTER_SYNC模式），用戶線程會釋放上一個stage的鎖，并等待ACk。這意味著在等待ACK的過程中，我們并不堵塞上一個stage的binlog寫入，可以增加一定的吞吐量。 4. Commit Stage：隊列中的事務依次進行innodb commit，將undo頭的狀態修改為`TRX_UNDO_CACHED`/`TRX_UNDO_TO_FREE`/`TRX_UNDO_TO_PURGE`任意一種 (undo相關知識參閱[之前的月報](http://mysql.taobao.org/monthly/2015/04/01/))；并釋放事務鎖，清理讀寫事務鏈表、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的文件結構：  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時不做回滾，僅設置事務標記即可。 具體的參閱我之前寫的[這篇月報](http://mysql.taobao.org/monthly/2015/04/05/) ## 事務回滾 當由于各種原因（例如死鎖，或者顯式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 鏈表 總共分為以下幾步： 1. 在增加新的SAVEPOINT時，總是先判斷下是否同名的SAVEPOINT已經存在，如果存在，就用后者替換前者； 2. Server層維護的savepoint信息記錄了命名信息及MDL鎖的savepoint點。其中MDL鎖的savepoint，可以實現回滾操作時釋放該savepoint之后再獲得的MDL鎖； 3. 在當前線程的Binlog cache中寫入設置Savepoint的SQL, 并保存binlog cache中的位點 （`binlog_savepoint_set`）； 4. 引擎層的savepoint中記錄了最近一次的`trx_t::undo_no`及SAVEPOINT名字。通過這些信息可以準確的定位在設置SAVEPOINT點時Undo位點。（參閱引擎層入口函數：`trx_savepoint_for_mysql`）。 回滾SAVEPOINT 語法：ROLLBACK TO [ SAVEPOINT ] sp_name 入口函數：`trans_rollback_to_savepoint` 檢查點的回滾主要包括： 1. 如果事務是一個XA事務，且已經處于XA PREPARE狀態時是不允許回滾到某個SAVEPOINT的； 2. 如果涉及非事務引擎，在binlog中寫入回滾SQL，否則直接將binlog cache truncate到之前設置sp時保存的位點。（`binlog_savepoint_rollback`） 3. 在引擎層進行回滾（`trx_rollback_to_savepoint_for_mysql`） 根據之前記錄的undo_no，可以逆向操作當前事務占用的undo slot上的undo記錄來進行回滾。 4. 判斷是否允許回滾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](http://bugs.mysql.com/bug.php?id=79493) 在一個只讀事務中，如果設置了SAVEPOINT，任意執行一次`ROLLBACK TO SAVEPOINT`都會將事務從只讀模式改變成讀寫模式。這主要是因為在活躍事務中執行ROLLBACK 操作會強制轉換READ-WRITE模式。實際上這是沒必要的，因為并沒有造成任何的數據變更。 [bug#79596](http://bugs.mysql.com/bug.php?id=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子系統，則主要用于在事務提交后，進行垃圾回收，以及數據頁的無效數據清理。 總的來說，事務管理模塊的架構圖，如下圖所示：  InnoDB 事務管理 下面就幾個事務模塊的關鍵點展開描述。 ### 事務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相關知識可以參閱之前的[月報](http://mysql.taobao.org/monthly/2015/04/01/) ### 事務引用計數 在介紹事務引用計數之前，我們首先要了解下什么是隱式鎖。所謂隱式鎖，其實并不是一個真正的事務鎖對象，可以理解為一個標記：對于聚集索引頁的更新，記錄本身天然帶事務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](http://dev.mysql.com/worklog/task/?id=6835)?獲取更過關于高優先級事務的信息。 ### trx_t::flush_observer 閱讀代碼時發現這個在5.7版本新加的變量，從它的命名可以看出，其應該和臟頁flush相關。`flush_observer`可以認為是一個標記，當某種操作完成時，對于帶這種標記的page(`buf_page_t::flush_observer`)，需要保證完全刷到磁盤上。 該變量主要解決早期5.7版本建索引耗時太久的[bug#74472](http://bugs.mysql.com/bug.php?id=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](http://bugs.mysql.com/bug.php?id=79005)。 另外purge系統在開始purge任務時，需去克隆`MVCC::m_views`鏈表上未被close的最老視圖，并在本地視圖中將該最老事務的事務ID也加入到不可見的事務DI集合`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這里不贅述，詳細參閱[之前月報](http://mysql.taobao.org/monthly/2015/04/01/) ### 可見性判斷 如上所述，聚集索引的可見性判斷和二級索引的可見性判斷略有不同。因為二級索引記錄并沒有存儲事務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這樣的數據更改，無需判斷可見性，而是單純的發現事務鎖沖突，直接堵塞操作。 ### 隔離級別 然而在不同的隔離級別下，可見性的判斷有很大的不同。 1. READ-UNCOMMITTED 在該隔離級別下會讀到未提交事務所產生的數據更改，這意味著可以讀到臟數據，實際上你可以從函數`row_search_mvcc中`發現，當從btree讀到一條記錄后，如果隔離級別設置成READ-UNCOMMITTED，根本不會去檢查可見性或是查看老版本。這意味著，即使在同一條SQL中，也可能讀到不一致的數據。 2. READ-COMMITTED 在該隔離級別下，可以在SQL級別做到一致性讀，當事務中的SQL執行完成時，ReadView被立刻釋放了，在執行下一條SQL時再重建ReadView。這意味著如果兩次查詢之間有別的事務提交了，是可以讀到不一致的數據的。 3. REPEATABLE-READ 可重復讀和READ-COMMITTED的不同之處在于，當第一次創建ReadView后（例如事務內執行的第一條SEELCT語句），這個視圖就會一直維持到事務結束。也就是說，在事務執行期間的可見性判斷不會發生變化，從而實現了事務內的可重復讀。 4. 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規則提交或者回滾事務。最終實例總能處于一致的狀態。 另外一種一致性指的是數據之間的約束不應該被事務所改變，例如外鍵約束。MySQL支持自動檢查外鍵約束，或是做級聯操作來保證數據完整性，但另外也提供了選項`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，以此來保證強持久化。你也可以選擇更弱化的配置來保證實例的性能。