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