讀?MySQL?源碼再看?INSERT?加鎖流程
[導(dǎo)讀]來源：https://www.aneasystone.com/archives/2018/06/insert-locks-via-mysql-source-code.html在之前的博客中，我寫了一系列的文章，比較系統(tǒng)的學(xué)習(xí)了MySQL的事務(wù)、隔離級(jí)別、加鎖流程以及死鎖，我自認(rèn)為...
來源：https://www.aneasystone.com/archives/2018/06/insert-locks-via-mysql-source-code.html
在之前的博客中，我寫了一系列的文章，比較系統(tǒng)的學(xué)習(xí)了 MySQL 的事務(wù)、隔離級(jí)別、加鎖流程以及死鎖，我自認(rèn)為對(duì)常見 SQL 語句的加鎖原理已經(jīng)掌握的足夠了，但看到熱心網(wǎng)友在評(píng)論中提出的一個(gè)問題，我還是徹底被問蒙了。他的問題是這樣的：
先執(zhí)行 SELECT 后執(zhí)行 INSERT：但是我們仔細(xì)想一想就會(huì)發(fā)現(xiàn)哪里有點(diǎn)不對(duì)勁，我們知道?insert?語句會(huì)先在插入間隙上加上插入意向鎖，然后開始寫數(shù)據(jù)，寫完數(shù)據(jù)之后再對(duì)記錄加上 X 記錄鎖（這里簡(jiǎn)化了，關(guān)于 insert 語句的加鎖流程，可以參考我之前寫的常見 SQL 語句的加鎖分析）。那么問題就來了，如果在 insert 語句加插入意向鎖之后，寫數(shù)據(jù)之前，執(zhí)行了 select...lock in share mode語句，這個(gè)時(shí)候 GAP 鎖和插入意向鎖是不沖突的，查詢出來的記錄數(shù)為 0，然后 insert 語句寫數(shù)據(jù)，加 X 記錄鎖，因?yàn)橛涗涙i和 GAP 鎖也是不沖突的，所以 insert 成功插入了一條數(shù)據(jù)，這個(gè)時(shí)候如果事務(wù)提交，select...lock in share mode 語句再次執(zhí)行查詢出來的記錄數(shù)就是 1，豈不是就出現(xiàn)了幻讀？
整個(gè)流程如下所示（我們把 insert 語句的執(zhí)行分成兩個(gè)階段，INSERT 1 加插入意向鎖，還沒寫數(shù)據(jù)，INSERT 2 寫數(shù)據(jù)，加記錄鎖）：一、INSERT 加鎖的困惑
在得出上面的結(jié)論時(shí)，我也感到很驚訝。按理是不可能出現(xiàn)這種情況的，只可能是我對(duì)這兩個(gè)語句的加鎖過程還沒有想明白。于是我又去復(fù)習(xí)了一遍 MySQL 官方文檔，Locks Set by Different SQL Statements in InnoDB 這篇文檔對(duì)各個(gè)語句的加鎖有詳細(xì)的描述，其中對(duì) insert 的加鎖過程是這樣說的（這應(yīng)該是網(wǎng)絡(luò)上介紹 MySQL 加鎖機(jī)制被引用最多的文檔，估計(jì)也是被誤解最多的文檔）：
在 Google 上搜索了很久，并沒有找到 MySQL 幻讀的問題，百思不得其解之際，遂決定從 MySQL 的源碼中一探究竟。這里我選擇的是 5.6.40 版本，操作系統(tǒng)下拉列表里選 Source Code，OS Version 選擇 Windows（Architecture Independent），然后就可以下載打包好的 zip 源碼了。
將源碼解壓縮到 D:\mysql-5.6.40?目錄，在編譯之前，還需要再安裝幾個(gè)必要軟件：另外，?client\Debug\mysql.exe 這個(gè)文件是對(duì)應(yīng)的 MySQL 的客戶端，可以直接雙擊運(yùn)行，默認(rèn)使用的用戶為 ODBC@localhost，如果要以 root 用戶登錄，可以執(zhí)行 mysql.exe -u root，不需要密碼。
那么我們來找下 insert 語句是在哪加插入意向鎖的。第一次看 MySQL 源碼可能會(huì)有些不知所措，調(diào)著調(diào)著就會(huì)迷失在深深的調(diào)用層級(jí)中，我們看 insert 語句的調(diào)用堆棧，一開始時(shí)還比較容易理解，從 mysql_parse -> mysql_execute_command -> mysql_insert -> write_record -> handler::ha_write_row -> innobase::write_row -> row_insert_for_mysql，這里就進(jìn)入 InnoDb 引擎了。然后繼續(xù)往下跟：row_ins_step -> row_ins -> row_ins_index_entry_step -> row_ins_index_entry -> row_ins_clust_index_entry -> row_ins_clust_index_entry_low -> btr_cur_optimistic_insert -> btr_cur_ins_lock_and_undo -> lock_rec_insert_check_and_lock。一路跟下來，都沒有發(fā)現(xiàn)插入意向鎖的蹤跡，直到 lock_rec_insert_check_and_lock 這里：
跟代碼非常辛苦，我擔(dān)心是因?yàn)槲腋鷣G了某塊的邏輯導(dǎo)致沒看到加鎖，于是我看了看加其他鎖的地方，發(fā)現(xiàn)在 InnoDb 里行鎖都是通過調(diào) lock_rec_add_to_queue（沒有鎖沖突） 或者 lock_rec_enqueue_waiting（有鎖沖突，需要等待其他事務(wù)釋放鎖） 來實(shí)現(xiàn)的，于是在這兩個(gè)函數(shù)上下斷點(diǎn)，執(zhí)行一條 insert 語句，依然沒有斷下來，說明 insert 語句沒有加任何鎖！到這里我突然想起之前做過的 insert 加鎖的實(shí)驗(yàn)，執(zhí)行 insert 之后，如果沒有任何沖突，在 show engine innodb status 命令中是看不到任何鎖的，這是因?yàn)?/span> insert 加的是隱式鎖。什么是隱式鎖？隱式鎖的意思就是沒有鎖！所以，根本就不存在之前說的先加插入意向鎖，再加排他記錄鎖的說法，在執(zhí)行 insert 語句時(shí)，什么鎖都不會(huì)加。這就有點(diǎn)意思了，如果 insert 什么鎖都不加，那么如果其他事務(wù)執(zhí)行 select ... lock in share mode，它是如何阻止其他事務(wù)加鎖的呢？答案就在于隱式鎖的轉(zhuǎn)換。InnoDb 在插入記錄時(shí)，是不加鎖的。如果事務(wù) A 插入記錄且未提交，這時(shí)事務(wù) B 嘗試對(duì)這條記錄加鎖，事務(wù) B 會(huì)先去判斷記錄上保存的事務(wù) id 是否活躍，如果活躍的話，那么就幫助事務(wù) A 去建立一個(gè)鎖對(duì)象，然后自身進(jìn)入等待事務(wù) A 狀態(tài)，這就是所謂的隱式鎖轉(zhuǎn)換為顯式鎖。我們跟一下執(zhí)行 select 時(shí)的流程，如果 select 需要加鎖，則會(huì)走：sel_set_rec_lock -> lock_clust_rec_read_check_and_lock -> lock_rec_convert_impl_to_expl，lock_rec_convert_impl_to_expl 函數(shù)的核心代碼如下：
在之前的博客中，我寫了一系列的文章，比較系統(tǒng)的學(xué)習(xí)了 MySQL 的事務(wù)、隔離級(jí)別、加鎖流程以及死鎖，我自認(rèn)為對(duì)常見 SQL 語句的加鎖原理已經(jīng)掌握的足夠了，但看到熱心網(wǎng)友在評(píng)論中提出的一個(gè)問題，我還是徹底被問蒙了。他的問題是這樣的：
加了插入意向鎖后，插入數(shù)據(jù)之前，此時(shí)執(zhí)行了 select…lock in share mode 語句（沒有取到待插入的值），然后插入了數(shù)據(jù)，下一次再執(zhí)行 select…lock in share mode（不會(huì)跟插入意向鎖沖突），發(fā)現(xiàn)多了一條數(shù)據(jù)，于是又產(chǎn)生了幻讀。會(huì)出現(xiàn)這種情況嗎？這個(gè)問題初看上去很簡(jiǎn)單，在 RR 隔離級(jí)別下，假設(shè)要插入的記錄不存在，如果先執(zhí)行 select...lock in share mode 語句，很顯然會(huì)在記錄間隙之間加上 GAP 鎖，而 insert 語句首先會(huì)對(duì)記錄加插入意向鎖，插入意向鎖和 GAP 鎖沖突，所以不存在幻讀；如果先執(zhí)行 insert 語句后執(zhí)行 select...lock in share mode 語句，由于 insert 語句在插入記錄之后，會(huì)對(duì)記錄加 X 鎖，它會(huì)阻止 select...lock in share mode 對(duì)記錄加 S 鎖，所以也不存在幻讀。兩種情況如下所示：先執(zhí)行 INSERT 后執(zhí)行 SELECT：
先執(zhí)行 SELECT 后執(zhí)行 INSERT：但是我們仔細(xì)想一想就會(huì)發(fā)現(xiàn)哪里有點(diǎn)不對(duì)勁，我們知道?insert?語句會(huì)先在插入間隙上加上插入意向鎖，然后開始寫數(shù)據(jù)，寫完數(shù)據(jù)之后再對(duì)記錄加上 X 記錄鎖（這里簡(jiǎn)化了，關(guān)于 insert 語句的加鎖流程，可以參考我之前寫的常見 SQL 語句的加鎖分析）。那么問題就來了，如果在 insert 語句加插入意向鎖之后，寫數(shù)據(jù)之前，執(zhí)行了 select...lock in share mode語句，這個(gè)時(shí)候 GAP 鎖和插入意向鎖是不沖突的，查詢出來的記錄數(shù)為 0，然后 insert 語句寫數(shù)據(jù)，加 X 記錄鎖，因?yàn)橛涗涙i和 GAP 鎖也是不沖突的，所以 insert 成功插入了一條數(shù)據(jù)，這個(gè)時(shí)候如果事務(wù)提交，select...lock in share mode 語句再次執(zhí)行查詢出來的記錄數(shù)就是 1，豈不是就出現(xiàn)了幻讀？整個(gè)流程如下所示（我們把 insert 語句的執(zhí)行分成兩個(gè)階段，INSERT 1 加插入意向鎖，還沒寫數(shù)據(jù)，INSERT 2 寫數(shù)據(jù)，加記錄鎖）：
一、INSERT 加鎖的困惑在得出上面的結(jié)論時(shí)，我也感到很驚訝。按理是不可能出現(xiàn)這種情況的，只可能是我對(duì)這兩個(gè)語句的加鎖過程還沒有想明白。于是我又去復(fù)習(xí)了一遍 MySQL 官方文檔，Locks Set by Different SQL Statements in InnoDB 這篇文檔對(duì)各個(gè)語句的加鎖有詳細(xì)的描述，其中對(duì) insert 的加鎖過程是這樣說的（這應(yīng)該是網(wǎng)絡(luò)上介紹 MySQL 加鎖機(jī)制被引用最多的文檔，估計(jì)也是被誤解最多的文檔）：
INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.講到了 insert 會(huì)對(duì)插入的這條記錄加排他記錄鎖，在加記錄鎖之前還會(huì)加一種 GAP 鎖，叫做插入意向鎖，如果出現(xiàn)唯一鍵沖突，還會(huì)加一個(gè)共享記錄鎖。這和我之前的理解是完全一樣的，那么究竟是怎么回事呢？難道 MySQL 的 RR 真的會(huì)出現(xiàn)幻讀現(xiàn)象？
Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to insert values of 5 and 6 each lock the gap between 4 and 7 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are nonconflicting.
If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock. This can occur if another session deletes the row.
在 Google 上搜索了很久，并沒有找到 MySQL 幻讀的問題，百思不得其解之際，遂決定從 MySQL 的源碼中一探究竟。
二、編譯 MySQL 源碼
編譯 MySQL 的源碼非常簡(jiǎn)單，但是中間也有幾個(gè)坑，如果能繞過這幾個(gè)坑，在本地調(diào)試 MySQL 是一件很容易的事（當(dāng)然能調(diào)試源碼是一回事，能看懂源碼又是另一回事了）。我的環(huán)境是 Windows 10 x64，系統(tǒng)上安裝了 Visual Studio 2012，如果你的開發(fā)環(huán)境和我不一樣，編譯步驟可能也會(huì)不同。在開始之前，首先要從官網(wǎng)下載 MySQL 源碼：這里我選擇的是 5.6.40 版本，操作系統(tǒng)下拉列表里選 Source Code，OS Version 選擇 Windows（Architecture Independent），然后就可以下載打包好的 zip 源碼了。將源碼解壓縮到 D:\mysql-5.6.40?目錄，在編譯之前，還需要再安裝幾個(gè)必要軟件：
- CMake：CMake 本身并不是編譯工具，它是通過編寫一種平臺(tái)無關(guān)的 CMakeList.txt 文件來定制編譯流程的，然后再根據(jù)目標(biāo)用戶的平臺(tái)進(jìn)一步生成所需的本地化 Makefile 和工程文件，如 Unix 的 Makefile 或 Windows 的 Visual Studio 工程；
- Bison：MySQL 在執(zhí)行 SQL 語句時(shí)，必然要對(duì) SQL 語句進(jìn)行解析，一般來說語法解析器會(huì)包含兩個(gè)模塊：詞法分析和語法規(guī)則。詞法分析和語法規(guī)則模塊有兩個(gè)較成熟的開源工具 Flex 和 Bison 分別用來解決這兩個(gè)問題。MySQL 出于性能和靈活考慮，選擇了自己完成詞法解析部分，語法規(guī)則部分使用了 Bison，所以這里我們還要先安裝 Bison。Bison 的默認(rèn)安裝路徑為 C:\Program Files\GnuWin32，但是千萬不要這樣，一定要記得選擇一個(gè)不帶空格的目錄，譬如 C:\GnuWin32 要不然在后面使用 Visual Studio 編譯 MySQL 時(shí)會(huì)卡死；
- Visual Studio：沒什么好說的，Windows 環(huán)境下估計(jì)沒有比它更好的開發(fā)工具了吧。
1D:\mysql-5.6.40>?mkdir?project
2D:\mysql-5.6.40>?cd?project
3D:\mysql-5.6.40\project>?cmake?-G?"Visual?Studio?11?2012?Win64"?..cmake 的-G 參數(shù)用于指定生成哪種類型的工程文件，這里是 Visual Studio 2012，可以直接輸入 cmake -G 查看支持的工程類型。如果沒問題，會(huì)在 project 目錄下生成一堆文件，其中 MySQL.sln 就是我們要用的工程文件，使用 Visual Studio 打開它。打開 MySQL.sln 文件，會(huì)在 Solution Explorer 看到 130 個(gè)項(xiàng)目，其中有一個(gè)叫 ALL_BUILD，這個(gè)時(shí)候如果直接編譯，編譯會(huì)失敗，在這之前，我們還要對(duì)代碼做點(diǎn)修改：- 首先是 sql\sql_locale.cc 文件，看名字就知道這個(gè)文件用于國(guó)際化與本土化，這個(gè)文件里有各個(gè)國(guó)家的語言字符，但是這個(gè)文件卻是 ANSI 編碼，所以要將其改成 Unicode 編碼；
- 打開 sql\mysqld.cc 文件的第 5239 行，將 DBUG_ASSERT(0)?改成 DBUG_ASSERT(1)，要不然調(diào)試時(shí)會(huì)觸發(fā)斷言；
另外，?client\Debug\mysql.exe 這個(gè)文件是對(duì)應(yīng)的 MySQL 的客戶端，可以直接雙擊運(yùn)行，默認(rèn)使用的用戶為 ODBC@localhost，如果要以 root 用戶登錄，可以執(zhí)行 mysql.exe -u root，不需要密碼。三、調(diào)試 INSERT 加鎖流程
首先我們創(chuàng)建一個(gè)數(shù)據(jù)庫 test，然后創(chuàng)建一個(gè)測(cè)試表 t，主鍵為 id，并插入測(cè)試數(shù)據(jù)：1use?test;
2create?table?t(id?int?NOT?NULL?AUTO_INCREMENT?,?PRIMARY?KEY?(id));
3insert?into?t(id)?values(1),(10),(20),(50);
然后我們開兩個(gè)客戶端會(huì)話，一個(gè)會(huì)話執(zhí)行 insert into t(id) value(30)，另一個(gè)會(huì)話執(zhí)行 select * from t where id = 30 lock in share mode。很顯然，如果我們能在 insert 語句加插入意向鎖之后寫數(shù)據(jù)之前下個(gè)斷點(diǎn)，再在另一個(gè)會(huì)話中執(zhí)行 select 就可以模擬出這種場(chǎng)景了。那么我們來找下 insert 語句是在哪加插入意向鎖的。第一次看 MySQL 源碼可能會(huì)有些不知所措，調(diào)著調(diào)著就會(huì)迷失在深深的調(diào)用層級(jí)中，我們看 insert 語句的調(diào)用堆棧，一開始時(shí)還比較容易理解，從 mysql_parse -> mysql_execute_command -> mysql_insert -> write_record -> handler::ha_write_row -> innobase::write_row -> row_insert_for_mysql，這里就進(jìn)入 InnoDb 引擎了。然后繼續(xù)往下跟：row_ins_step -> row_ins -> row_ins_index_entry_step -> row_ins_index_entry -> row_ins_clust_index_entry -> row_ins_clust_index_entry_low -> btr_cur_optimistic_insert -> btr_cur_ins_lock_and_undo -> lock_rec_insert_check_and_lock。一路跟下來，都沒有發(fā)現(xiàn)插入意向鎖的蹤跡，直到 lock_rec_insert_check_and_lock 這里：
1if?(lock_rec_other_has_conflicting(
2????????static_cast<enum?lock_mode>(
3????????????LOCK_X?|?LOCK_GAP?|?LOCK_INSERT_INTENTION),
4????????block,?next_rec_heap_no,?trx))?{
5
6????/*?Note?that?we?may?get?DB_SUCCESS?also?here!?*/
7????trx_mutex_enter(trx);
8
9????err?=?lock_rec_enqueue_waiting(
10????????LOCK_X?|?LOCK_GAP?|?LOCK_INSERT_INTENTION,
11????????block,?next_rec_heap_no,?index,?thr);
12
13????trx_mutex_exit(trx);
14}?else?{
15????err?=?DB_SUCCESS;
16}
這里是檢查是否有和插入意向鎖沖突的其他鎖，如果有沖突，就將插入意向鎖加到鎖等待隊(duì)列中。這很顯然是先執(zhí)行 select ... lock in share mode 語句再執(zhí)行 insert 語句時(shí)的情景，插入意向鎖和 GAP 沖突。但這不是我們要找的點(diǎn)，于是繼續(xù)探索，但是可惜的是，直到 insert 執(zhí)行結(jié)束，我都沒有找到加插入意向鎖的地方。跟代碼非常辛苦，我擔(dān)心是因?yàn)槲腋鷣G了某塊的邏輯導(dǎo)致沒看到加鎖，于是我看了看加其他鎖的地方，發(fā)現(xiàn)在 InnoDb 里行鎖都是通過調(diào) lock_rec_add_to_queue（沒有鎖沖突） 或者 lock_rec_enqueue_waiting（有鎖沖突，需要等待其他事務(wù)釋放鎖） 來實(shí)現(xiàn)的，于是在這兩個(gè)函數(shù)上下斷點(diǎn)，執(zhí)行一條 insert 語句，依然沒有斷下來，說明 insert 語句沒有加任何鎖！到這里我突然想起之前做過的 insert 加鎖的實(shí)驗(yàn)，執(zhí)行 insert 之后，如果沒有任何沖突，在 show engine innodb status 命令中是看不到任何鎖的，這是因?yàn)?/span> insert 加的是隱式鎖。什么是隱式鎖？隱式鎖的意思就是沒有鎖！所以，根本就不存在之前說的先加插入意向鎖，再加排他記錄鎖的說法，在執(zhí)行 insert 語句時(shí)，什么鎖都不會(huì)加。這就有點(diǎn)意思了，如果 insert 什么鎖都不加，那么如果其他事務(wù)執(zhí)行 select ... lock in share mode，它是如何阻止其他事務(wù)加鎖的呢？答案就在于隱式鎖的轉(zhuǎn)換。InnoDb 在插入記錄時(shí)，是不加鎖的。如果事務(wù) A 插入記錄且未提交，這時(shí)事務(wù) B 嘗試對(duì)這條記錄加鎖，事務(wù) B 會(huì)先去判斷記錄上保存的事務(wù) id 是否活躍，如果活躍的話，那么就幫助事務(wù) A 去建立一個(gè)鎖對(duì)象，然后自身進(jìn)入等待事務(wù) A 狀態(tài)，這就是所謂的隱式鎖轉(zhuǎn)換為顯式鎖。我們跟一下執(zhí)行 select 時(shí)的流程，如果 select 需要加鎖，則會(huì)走：sel_set_rec_lock -> lock_clust_rec_read_check_and_lock -> lock_rec_convert_impl_to_expl，lock_rec_convert_impl_to_expl 函數(shù)的核心代碼如下：
1impl_trx?=?trx_rw_is_active(trx_id,?NULL);
2
3if?(impl_trx?!=?NULL
4???? 
下載文檔
