mysql 關於innodb中MVCC的一些理解

2021-07-23 04:48:41 字數 2488 閱讀 1218

mvcc (multiversion concurrency control),即多版本併發控制技術,它使得大部分支援行鎖的事務引擎,不再單純的使用行鎖來進行資料庫的併發控制,取而代之的是把資料庫的行鎖與行的多個版本結合起來,只需要很小的開銷,就可以實現非鎖定讀,從而大大提高資料庫系統的併發效能

讀鎖:也叫共享鎖、s鎖,若事務t對資料物件a加上s鎖,則事務t可以讀a但不能修改a,其他事務只能再對a加s鎖,而不能加x鎖,直到t釋放a上的s 鎖。這保證了其他事務可以讀a,但在t釋放a上的s鎖之前不能對a做任何修改。

寫鎖:又稱排他鎖、x鎖。若事務t對資料物件a加上x鎖,事務t可以讀a也可以修改a,其他事務不能再對a加任何鎖,直到t釋放a上的鎖。這保證了其他事務在t釋放a上的鎖之前不能再讀取和修改a。

表鎖:操作物件是資料表。mysql大多數鎖策略都支援(常見mysql innodb),是系統開銷最低但併發性最低的乙個鎖策略。事務t對整個表加讀鎖,則其他事務可讀不可寫,若加寫鎖,則其他事務增刪改都不行。

行級鎖:操作物件是資料表中的一行。是mvcc技術用的比較多的,但在myisam用不了,行級鎖用mysql的儲存引擎實現而不是mysql伺服器。但行級鎖對系統開銷較大,處理高併發較好。

innodb mvcc主要是為repeatable-read事務隔離級別做的。在此隔離級別下,a、b客戶端所示的資料相互隔離,互相更新不可見

了解innodb的行結構、read-view的結構對於理解innodb mvcc的實現由重要意義

innodb儲存的最基本row中包含一些額外的儲存資訊 data_trx_id,data_roll_ptr,db_row_id,delete bit

具體的執行過程

begin->用排他鎖鎖定該行->記錄redo log->記錄undo log->修改當前行的值,寫事務編號,回滾指標指向undo log中的修改前的行

上述過程確切地說是描述了update的事務過程,其實undo log分insert和update undo log,因為insert時,原始的資料並不存在,所以回滾時把insert undo log丟棄即可,而update undo log則必須遵守上述過程

下面分別以select、delete、 insert、 update語句來說明

select

innodb檢查每行資料,確保他們符合兩個標準:

1、innodb只查詢版本早於當前事務版本的資料行(也就是資料行的版本必須小於等於事務的版本),這確保當前事務讀取的行都是事務之前已經存在的,或者是由當前事務建立或修改的行

2、行的刪除操作的版本一定是未定義的或者大於當前事務的版本號,確定了當前事務開始之前,行沒有被刪除

符合了以上兩點則返回查詢結果。

insert

innodb為每個新增行記錄當前系統版本號作為建立id。

delete

innodb為每個刪除行的記錄當前系統版本號作為行的刪除id。

update

innodb複製了一行。這個新行的版本號使用了系統版本號。它也把系統版本號作為了刪除行的版本。

說明insert操作時 「建立時間」=db_row_id,這時,「刪除時間 」是未定義的;

update時,複製新增行的「建立時間」=db_row_id,刪除時間未定義,舊資料行「建立時間」不變,刪除時間=該事務的db_row_id;

delete操作,相應資料行的「建立時間」不變,刪除時間=該事務的db_row_id;

select操作對兩者都不修改,唯讀相應的資料

上述更新前建立undo log,根據各種策略讀取時非阻塞就是mvcc,undo log中的行就是mvcc中的多版本,這個可能與我們所理解的mvcc有較大的出入,一般我們認為mvcc有下面幾個特點:

就是每行都有版本號,儲存時根據版本號決定是否成功,聽起來含有樂觀鎖的味道,而innodb的實現方式是:

二者最本質的區別是,當修改資料時是否要排他鎖定,如果鎖定了還算不算是mvcc? 

innodb的實現真算不上mvcc,因為並沒有實現核心的多版本共存,undo log中的內容只是序列化的結果,記錄了多個事務的過程,不屬於多版本共存。但理想的mvcc是難以實現的,當事務僅修改一行記錄使用理想的mvcc模式是沒有問題的,可以通過比較版本號進行回滾;但當事務影響到多行資料時,理想的mvcc據無能為力了。

比如,如果transaciton1執行理想的mvcc,修改row1成功,而修改row2失敗,此時需要回滾row1,但因為row1沒有被鎖定,其資料可能又被transaction2所修改,如果此時回滾row1的內容,則會破壞transaction2的修改結果,導致transaction2違反acid。

理想mvcc難以實現的根本原因在於企圖通過樂觀鎖代替二段提交。修改兩行資料,但為了保證其一致性,與修改兩個分布式系統中的資料並無區別,而二提交是目前這種場景保證一致性的唯一手段。二段提交的本質是鎖定,樂觀鎖的本質是消除鎖定,二者矛盾,故理想的mvcc難以真正在實際中被應用,innodb只是借了mvcc這個名字,提供了讀的非阻塞而已。

參考文章

關於Mysql的儲存引擎Innodb和Myisam

myisam和innodb 都是採用 b tree這種資料結構來實現 b tree索引。而很大的區別在於,innodb 儲存引擎採用 聚集索引 的資料儲存方式實現b tree索引,所謂 聚集 就是指資料行和相鄰的鍵值緊湊地儲存在一起,注意 innodb 只能聚集乙個葉子頁 16k 的記錄 即聚集索引...

mysql 關於innodb中MVCC的一些理解

mvcc multiversion concurrency control 即多版本併發控制技術,它使得大部分支援行鎖的事務引擎,不再單純的使用行鎖來進行資料庫的併發控制,取而代之的是把資料庫的行鎖與行的多個版本結合起來,只需要很小的開銷,就可以實現非鎖定讀,從而大大提高資料庫系統的併發效能 讀鎖 ...

MySQL的innodb引擎是如何實現MVCC的

索引的資料結構有b treee索引和hash索引 b treee索引是innodb引擎預設使用的資料結構,它通過一定的演算法,將mysql表中資料分磁碟存放,少量的磁碟讀取即可做到大量資料的遍歷 hash索引根據hash演算法將資料,精確的存放,來查詢某個資料的時候,根據相同的演算法一次就能找到,等...