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中）。

如下圖所示：

總共分為以下幾步：

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

在一個只讀事務中，如果設定了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

1. 持有lock_sys->mutex；
2. 持有trx_sys->mutex ，並獲取當前記錄中的事務id對應的記憶體事務物件trx_t
3. 為該事務建立一個鎖物件，並加入到鎖佇列中。
4. 釋放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，以此來保證強持久化。你也可以選擇更弱化的配置來保證例項的效能。