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