事物的隔離性和MVCC

  • 2022 年 8 月 28 日
  • 筆記

事物的隔離性

mysql的服務端是支援多個客戶端同時與之連接的,每個客戶端可能還並發了好幾個連接,所以mysql是需要同時處理很多事情的,每一件獨立的事情就叫做事務。我們知道事務有一個叫隔離性的特性,隔離性理論上是指在某個事物對某個數據進行訪問時,其他的事務就應該排隊知道訪問數據的事務提交才能繼續訪問該數據。但是這樣對性能的影響就太大了,但是我們又必須保持一定的隔離性,所以就需要折中一下。

事務並發可能的問題

先來看看不保證絕對的隔離性會遇到哪些問題呢

  • 臟寫

如果一個事務修改了另一個未提交事務修改過的數據,這就意味著發生了臟寫。

  • 臟讀

如果一個事務讀到了另一個未提交事務修改過的數據,這就意味著發生了臟讀。

  • 不可重複讀

如果同一個事務中能讀到其他事務提交後的最新值,這時其他事務對這個數據進行的每次改動都會讓該事務讀到不同最新值,這就意味著發生了不可重複讀。

  • 幻讀

如果一個事務根據某些查出一些記錄,之後另一個事務又向表中插入了符合這些條件的記錄,該事務再次用該條件查詢的時候,就會查出上次查沒查到的數據即另一個事務剛插入的數據,這就是幻讀。

小貼士:

不可重複讀和幻讀確實有點相似,但不可重複讀重點在於update和delete,而幻讀的重點在於insert。對於前者,要避免只需鎖住滿足條件的已有記錄即可,避免後者就需要鎖住滿足條件的記錄(包括存在的和不存在的),不存在的記錄如何才能鎖住呢?所以鎖的範圍需要擴大到滿足條件的相鄰範圍的記錄(臨鍵鎖)

事務的隔離級別

這時就出現了一個標準用來定義上面說的折中的程度,在SQL標準中定義了4個隔離級別:

  • READ UNCOMMITTED:讀未提交
  • READ COMMITTED:讀已提交
  • REPEATABLE READ:可重複讀
  • SERIALIZABLE:可串列化

SQL標準中規定,針對不同的隔離級別並發事務可以發生不同嚴重程度的問題

MVCC

MVCC解決了事務並發時讀和寫同時進行互不影響的問題,從而提升系統性能。mvcc並不能解決完全解決臟讀和不可重複讀的問題,如果innoDB只有mvcc沒有鎖,那麼當前事務確實沒辦法讀取到未提交的數據,但是可以修改。

對於讀已提交和可重複讀的事務來說,都必須保證讀到的記錄是已經提交了的事務修改的記錄,所以如果想做到讀寫互不影響,核心問題就是讀取記錄時需判斷版本鏈中的哪個版本是對當前事務可見。

MVCC原理

對於innoDB存儲引擎來說,每張表中都含有兩個必要的隱藏列trx_id和roll_pointer。每次對某條記錄進行改動時,都會把舊的版本寫入到 undo日誌中,然後在這個roll_pointer列中存儲舊版本在undo日誌的地址,可以通過它來找到該記錄修改前的資訊,同時將進行改動的事務id寫入trx_id列。

 

在可重複讀的隔離模式下每個事務都會生成一個 ReadView ,主要包含4個重要的內容:

m_ids :表示在生成 ReadView 時當前系統中活躍的讀寫事務的 事務id 列表。

min_trx_id :表示在生成 ReadView 時當前系統中活躍的讀寫事務中最小的 事務id ,也就是

m_ids 中的最 小值。

max_trx_id :表示生成 ReadView 時系統中應該分配給下一個事務的 id 值。

creator_trx_id :表示生成該 ReadView 的事務的 事務id 。

有了這個 ReadView ,這樣在訪問某條記錄時,只需要按照下邊的步驟判斷記錄的某個版本是否可見:

如果被訪問版本的 trx_id 屬性值與 ReadView 中的 creator_trx_id 值相同,意味著當前事務在訪問它自己 修改過的記錄,所以該版本可以被當前事務訪問。

如果被訪問版本的 trx_id 屬性值小於 ReadView 中的 min_trx_id 值,表明生成該版本的事務在當前事務生 成 ReadView 前已經提交,所以該版本可以被當前事務訪問。

如果被訪問版本的 trx_id 屬性值大於 ReadView 中的 max_trx_id 值,表明生成該版本的事務在當前事務生 成 ReadView 後才開啟,所以該版本不可以被當前事務訪問。

如果被訪問版本的 trx_id 屬性值在 ReadView 的 min_trx_id 和 max_trx_id 之間,那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中,如果在,說明創建 ReadView 時生成該版本的事務還是活躍的,該版本不可以被訪問;如果不在,說明創建 ReadView 時生成該版本的事務已經被提交,該版本可以被訪問。

如果某個版本的數據對當前事務不可見的話,那就順著版本鏈找到下一個版本的數據,繼續按照上邊的步驟判斷 可見性,依此類推,直到版本鏈中的最後一個版本。如果最後一個版本也不可見的話,那麼就意味著該條記錄對 該事務完全不可見,查詢結果就不包含該記錄。

上面兩段引用來自於《MySQL是怎樣運行的:從根兒上理解MySQL》,我覺得已經很明白了。

 

我寫文章都是力求正確,但水平有限,歡迎大佬斧正。

 

相關資源:

MySQL是怎樣運行的:從根兒上理解MySQL