站長資訊網(wǎng)
MySQL是如何解決幻讀問題的？下面本篇文章就來帶大家聊聊這個(gè)問題，下面就來帶著問題一起看看文章吧！
??金不三，銀不四的高頻面試題中，MySQL的事務(wù)特性，隔離級別等問題也是非常經(jīng)典八股文之一，面對此種問題，估計(jì)絕大數(shù)小伙伴也是信手拈來的事情：
事務(wù)特性（ACID）：原子性（Atomicity）、隔離性（Isolation）、一致性（Consistency）和持久性
隔離級別：讀取未提交（READ UNCOMMITTED），讀取已提交（READ COMMITTED），可重復(fù)讀（REPEATABLE READ），可串行化（SERIALIZABLE）
而每一種隔離級別導(dǎo)致的問題有：
READ UNCOMMITTED隔離級別下，可能發(fā)生臟讀、不可重復(fù)讀和幻讀問題READ COMMITTED隔離級別下，可能發(fā)生不可重復(fù)讀和幻讀問題，但是不可以發(fā)生臟讀問題REPEATABLE READ隔離級別下，可能發(fā)生幻讀問題，但是不可以發(fā)生臟讀和不可重復(fù)讀的問題SERIALIZABLE隔離級別下，各種問題都不可以發(fā)生
對于MySQL InnoDB 存儲引擎的默認(rèn)支持的隔離級別是 REPEATABLE-READ（可重讀），從上面的SQL標(biāo)準(zhǔn)的四種隔離級別定義可知，REPEATABLE-READ(可重復(fù)讀)是不可以防止幻讀的，但是我們都知道，MySQL InnoDB存儲引擎是解決了幻讀問題發(fā)生的，那他又是如何解決的呢？
1. 行格式
??在進(jìn)入主題之前，我們先大致了解一下什么是行格式，這樣有助于我們理解下面的MVCC，行格式是表中的行記錄在磁盤的存放方式，Innodb存儲引擎總共有4種不同類型的行格式：compact、redundant、dynamic、compress；雖然很很多行格式，但是在原理上，大體都相同，如下，為compact行格式：
??從圖中可以看出來，一條完整的記錄其實(shí)可以被分為記錄的額外信息和記錄的真實(shí)數(shù)據(jù)兩大部分，記錄的額外信息分別是變長字段長度列表、NULL值列表和記錄頭信息，而記錄的真實(shí)數(shù)據(jù)除了我們自己定義的列之外，MySQL會為每個(gè)記錄添加一些默認(rèn)列，這些默認(rèn)列又稱為隱藏列，具體列如下：
| 列名 | 長度 | 描述 |
|---|---|---|
| row_id | 6個(gè)字節(jié) | 行ID，唯一標(biāo)識一條記錄 |
| transaction_id | 6個(gè)字節(jié) | 事務(wù)ID |
| roll_pointer | 7個(gè)字節(jié) | 回滾指針 |
隱藏列的值不用我們操心，InnoDB存儲引擎會自己幫我們生成的，畫得再詳細(xì)一點(diǎn)，compact行格式如下：
- transaction_id ：事物id，當(dāng)事物對行記錄進(jìn)行修改時(shí)，都會將本事物的事物id賦值到該列
- roll_pointer：每次在對行記錄進(jìn)行改動的時(shí)候，都會把舊版本的數(shù)據(jù)寫入undolog日志，
然后將roll_pointer指向該undolog，所以該列相當(dāng)于一個(gè)指針，通過該列，可以找到修改之前的信息
2. MVCC詳解
2.1 版本鏈
假設(shè)有一條記錄如下：
插入該記錄的事務(wù)id為80，roll_pointer 指針為NULL(為了便于理解，讀者可理解為指向?yàn)镹ULL，實(shí)際上roll_pointer第一個(gè)比特位就標(biāo)記著它指向的undo日志的類型，如果該比特位的值為1時(shí)，就代表著它指向的undo日志類型為insert undo)
假設(shè)之后兩個(gè)事務(wù)id分別為100、200的事務(wù)對這條記錄進(jìn)行UPDATE操作：
-- 事務(wù)id=100 update person set grade =20 where id =1; update person set grade =40 where id =1; -- 事務(wù)id=200 update person set grade =70 where id =1;
??每次對記錄進(jìn)行改動，都會記錄一條undo日志，每條undo日志也都有一個(gè)roll_pointer屬性（INSERT操作對應(yīng)的undo日志沒有該屬性，因?yàn)樵撚涗洸]有更早的版本），可以將這些undo日志都連起來，串成一個(gè)鏈表，所以現(xiàn)在的情況就像下圖一樣:
??對該記錄每次更新后，都會將舊值放到一條undo日志中，就算是該記錄的一個(gè)舊版本，隨著更新次數(shù)的增多，所有的版本都會被roll_pointer屬性連接成一個(gè)鏈表，我們把這個(gè)鏈表稱之為版本鏈，版本鏈的頭節(jié)點(diǎn)就是當(dāng)前記錄最新的值。另外，每個(gè)版本中還包含生成該版本時(shí)對應(yīng)的事務(wù)id
2.2 ReadView
??對于數(shù)據(jù)庫的四種隔離級別：1)read uncommitted；2) read committed；3) REPEATABLE READ； 4)SERIALIZABLE；來說，READ UNCOMMITTED，每次讀取版本鏈的最新數(shù)據(jù)即可；SERIALIZABLE，主要是通過加鎖控制；而read committed和REPEATABLE READ都是讀取已經(jīng)提交了的事物，所以對于這兩個(gè)隔離級別，核心問題是版本鏈中，哪些事物是對當(dāng)前事物可見；為了解決這個(gè)問題，MySQL提出了read view 概念，其包含四個(gè)核心概念：
m_ids：生成read view時(shí)候，活躍的事物id集合min_trx_id：m_ids的最小值，既生成read view的時(shí)候，活躍事物的最小值max_trx_id：表示生成read view的時(shí)候，系統(tǒng)應(yīng)該分配下一個(gè)事物id值creator_trx_id：創(chuàng)建read view的事物id，即當(dāng)前事物id。
有了這個(gè)ReadView，這樣在訪問某條記錄時(shí)，只需要按照下邊的步驟判斷記錄的某個(gè)版本是否可見：
- 當(dāng)記錄的事物id等于
creator_trx_id的時(shí)候，說明當(dāng)前事物正在訪問自己修改的記錄，所以該版本可見 - 如果被訪問的版本事物id小于
min_trx_id的時(shí)候，則說明，在創(chuàng)建read view的時(shí)候，該事物已經(jīng)提交，該版本，對當(dāng)前事物可讀 - 如果被訪問的版本事物id大于或等于
max_trx_id，則說明創(chuàng)建該read view的時(shí)候，該說明生成該版本記錄的事物id在生成Read view之后才開啟，所以該版本不能被當(dāng)前事物可讀 - 如果被訪問的版本事物
transaction_id在m_ids集合中，說明生成Read view的時(shí)候，該事物還是活躍的，還沒有被提交，則該版本不可以被訪問；如果不在，則說明創(chuàng)建ReadView時(shí)生成該版本的事務(wù)已經(jīng)被提交，可以被訪問
注：讀事物的事物id為0
在MySQL中，READ COMMITTED和REPEATABLE READ隔離級別的的一個(gè)非常大的區(qū)別就是它們生成ReadView的時(shí)機(jī)不同:
READ COMMITTED—— 每次讀取數(shù)據(jù)前都生成一個(gè)ReadViewREPEATABLE READ—— 在第一次讀取數(shù)據(jù)時(shí)生成一個(gè)ReadView
下面我們通過詳細(xì)例子來說明，兩者有何不同：
| 時(shí)間編號 | trx 100 | trx 200 | |
|---|---|---|---|
| ① | BEGIN; | ||
| ② | BEGIN; | BEGIN; | |
| ③ | update person set grade =20 where id =1; | ||
| ④ | update person set grade =40 where id =1; | ||
| ⑤ | SELECT * FROM person WHERE id = 1; | ||
| ⑥ | COMMIT; | ||
| ⑦ | update person set grade =70 where id =1; | ||
| ⑧ | SELECT * FROM person WHERE id = 1; | ||
| ⑨ | COMMIT; | ||
| ? | COMMIT; |
在時(shí)間④中，因事務(wù)trx 100 執(zhí)行了事務(wù)的提交，id=1行記錄的版本鏈如下：
在時(shí)間⑥中，因事務(wù)trx 200 執(zhí)行了事務(wù)的提交，id=1行記錄的版本鏈如下：
在時(shí)間⑤，事務(wù)trx 100執(zhí)行select語句時(shí)會先生成一個(gè)ReadView，ReadView的m_ids列表的內(nèi)容就是[100, 200]，min_trx_id為100，max_trx_id為201，creator_trx_id為0，此時(shí)，從版本鏈中選可見的記錄，版本鏈從上到下遍歷：因?yàn)間rade=40，trx_id值為100，在m_ids里，所以該記錄不可見，同理，grade=20的也不見。繼續(xù)往下遍歷，grade=20,trx_id值為80,小于小于ReadView中的min_trx_id值100，所以這個(gè)版本符合要求，返回給用戶的是等級為10的記錄。
在時(shí)間⑧中，如果事務(wù)的隔離級別是READ COMMITTED，會單獨(dú)又生成一個(gè)ReadView，該ReadView的m_ids列表的內(nèi)容就是[200]，min_trx_id為200，max_trx_id為201，creator_trx_id為0，此時(shí)，從版本鏈中選可見的記錄，版本鏈從上到下遍歷：因?yàn)間rade=70，trx_id值為200，在m_ids里，所以該記錄不可見，繼續(xù)往下遍歷，grade=40,trx_id值為100，小于ReadView中的min_trx_id值200，所以這個(gè)版本是符合要求的，返回給用戶的是是等級為40的記錄。
在時(shí)間⑧中，如果事務(wù)的隔離級別是 REPEATABLE READ，在時(shí)間⑧中，不會單獨(dú)生成一個(gè)ReadView，而是沿用時(shí)間5的ReadView，所以返回給用戶的等級是10。前后兩次select得到的是一樣的，這就是可重復(fù)讀的含義。
3. 總結(jié)
??通過分析MVCC詳解部分，可以得出，基于MVCC，在RR隔離級別下，很好解決了幻讀問題，但是我們知道，select for update是產(chǎn)生當(dāng)前讀，不再是快照讀，那么此種情況，MySQL又是怎么解決幻讀問題的呢？基于時(shí)間問題(整理畫圖的確需要花比較多的時(shí)間)，此處先給結(jié)論，后面再分析在當(dāng)前讀的情況下，MySQL是怎么解決幻讀問題：
- 當(dāng)前讀 ： 使用 Next-Key Lock（間隙鎖） 進(jìn)行加鎖來保證不出現(xiàn)幻讀
對于間隙鎖是如何在當(dāng)前讀的情況下解決幻讀問題的，感興趣朋友可加個(gè)關(guān)注，點(diǎn)個(gè)贊
【
