您好,登錄后才能下訂單哦!
這篇文章主要介紹“MySQL如何解決幻讀問題”,在日常操作中,相信很多人在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存儲引擎是解決了幻讀問題發生的,那他又是如何解決的呢?
??在進入主題之前,我們先大致了解一下什么是行格式,這樣有助于我們理解下面的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
,所以該列相當于一個指針,通過該列,可以找到修改之前的信息
假設有一條記錄如下:插入該記錄的事務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
??對于數據庫的四種隔離級別: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
—— 每次讀取數據前都生成一個ReadView
REPEATABLE 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得到的是一樣的,這就是可重復讀
的含義。
到此,關于“MySQL如何解決幻讀問題”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。