1. 程式人生 > >輕鬆理解MYSQL MVCC 實現機制-(1)

輕鬆理解MYSQL MVCC 實現機制-(1)

1. MVCC簡介

1.1 什麼是MVCC

MVCC是一種多版本併發控制機制(Multi-Version Concurrency Control)。

1.2 MVCC是為了解決什麼問題?

  • 大多數的MYSQL事務型儲存引擎,如,InnoDB,Falcon以及PBXT都不使用一種簡單的行鎖機制.事實上,他們都和MVCC–多版本併發控制來一起使用.
  • 大家都應該知道,鎖機制可以控制併發操作,但是其系統開銷較大,而MVCC可以在大多數情況下代替行級鎖,使用MVCC,能降低其系統開銷.

1.3 MVCC實現

MVCC是通過儲存資料在某個時間點的快照來實現的. 不同儲存引擎的MVCC. 不同儲存引擎的MVCC實現是不同的,典型的有樂觀併發控制和悲觀併發控制.

2.MVCC 具體實現分析

下面,我們通過InnoDB的MVCC實現來分析MVCC使怎樣進行併發控制的. 
InnoDB的MVCC,是通過在每行記錄後面儲存兩個隱藏的列來實現的,這兩個列,分別儲存了這個行的建立時間,一個儲存的是行的刪除時間。這裡儲存的並不是實際的時間值,而是系統版本號(可以理解為事務的ID),沒開始一個新的事務,系統版本號就會自動遞增,事務開始時刻的系統版本號會作為事務的ID.下面看一下在REPEATABLE READ隔離級別下,MVCC具體是如何操作的.

2.1簡單的小例子

create table yang( 
id int primary key auto_increment, 
name varchar(20));

假設系統的版本號從1開始.

INSERT

InnoDB為新插入的每一行儲存當前系統版本號作為版本號. 
第一個事務ID為1;

start transaction;
insert into yang values(NULL,'yang') ;
insert into yang values(NULL,'long');
insert into yang values(NULL,'fei');
commit;
  • 1
  • 2
  • 3
  • 4
  • 5

對應在資料中的表如下(後面兩列是隱藏列,我們通過查詢語句並看不到)

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 undefined
2 long 1 undefined
3 fei 1 undefined

SELECT

InnoDB會根據以下兩個條件檢查每行記錄: 
a.InnoDB只會查詢版本早於當前事務版本的資料行(也就是,行的系統版本號小於或等於事務的系統版本號),這樣可以確保事務讀取的行,要麼是在事務開始前已經存在的,要麼是事務自身插入或者修改過的. 
b.行的刪除版本要麼未定義,要麼大於當前事務版本號,這可以確保事務讀取到的行,在事務開始之前未被刪除. 
只有a,b同時滿足的記錄,才能返回作為查詢結果.

DELETE

InnoDB會為刪除的每一行儲存當前系統的版本號(事務的ID)作為刪除標識. 
看下面的具體例子分析: 
第二個事務,ID為2;

start transaction;
select * from yang;  //(1)
select * from yang;  //(2)
commit; 
  • 1
  • 2
  • 3
  • 4

假設1

假設在執行這個事務ID為2的過程中,剛執行到(1),這時,有另一個事務ID為3往這個表裡插入了一條資料; 
第三個事務ID為3;

start transaction;
insert into yang values(NULL,'tian');
commit;
  • 1
  • 2
  • 3

這時表中的資料如下:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 undefined
2 long 1 undefined
3 fei 1 undefined
4 tian 3 undefined

然後接著執行事務2中的(2),由於id=4的資料的建立時間(事務ID為3),執行當前事務的ID為2,而InnoDB只會查詢事務ID小於等於當前事務ID的資料行,所以id=4的資料行並不會在執行事務2中的(2)被檢索出來,在事務2中的兩條select 語句檢索出來的資料都只會下表:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 undefined
2 long 1 undefined
3 fei 1 undefined

假設2

假設在執行這個事務ID為2的過程中,剛執行到(1),假設事務執行完事務3後,接著又執行了事務4; 
第四個事務:

start   transaction;  
delete from yang where id=1;
commit;  
  • 1
  • 2
  • 3

此時資料庫中的表如下:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 4
2 long 1 undefined
3 fei 1 undefined
4 tian 3 undefined

接著執行事務ID為2的事務(2),根據SELECT 檢索條件可以知道,它會檢索建立時間(建立事務的ID)小於當前事務ID的行和刪除時間(刪除事務的ID)大於當前事務的行,而id=4的行上面已經說過,而id=1的行由於刪除時間(刪除事務的ID)大於當前事務的ID,所以事務2的(2)select * from yang也會把id=1的資料檢索出來.所以,事務2中的兩條select 語句檢索出來的資料都如下:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 4
2 long 1 undefined
3 fei 1 undefined

UPDATE

InnoDB執行UPDATE,實際上是新插入了一行記錄,並儲存其建立時間為當前事務的ID,同時儲存當前事務ID到要UPDATE的行的刪除時間.

假設3

假設在執行完事務2的(1)後又執行,其它使用者執行了事務3,4,這時,又有一個使用者對這張表執行了UPDATE操作: 
第5個事務:

start  transaction;
update yang set name='Long' where id=2;
commit;
  • 1
  • 2
  • 3

根據update的更新原則:會生成新的一行,並在原來要修改的列的刪除時間列上新增本事務ID,得到表如下:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 4
2 long 1 5
3 fei 1 undefined
4 tian 3 undefined
2 Long 5 undefined

繼續執行事務2的(2),根據select 語句的檢索條件,得到下表:

id name 建立時間(事務ID) 刪除時間(事務ID)
1 yang 1 4
2 long 1 5
3 fei 1 undefined

還是和事務2中(1)select 得到相同的結果.

轉自:https://blog.csdn.net/whoamiyang/article/details/51901888