MYSQL中的樂觀鎖實(shí)現(xiàn)(MVCC)簡析
什么是MVCC
MVCC即Multi-Version Concurrency Control，中文翻譯過來叫多版本并發(fā)控制。
MVCC是解決了什么問題
眾所周知，在MYSQL中，MyISAM使用的是表鎖，InnoDB使用的是行鎖。而InnoDB的事務(wù)分為四個(gè)隔離級別，其中默認(rèn)的隔離級別REPEATABLE READ需要兩個(gè)不同的事務(wù)相互之間不能影響，而且還能支持并發(fā)，這點(diǎn)悲觀鎖是達(dá)不到的，所以REPEATABLE READ采用的就是樂觀鎖，而樂觀鎖的實(shí)現(xiàn)采用的就是MVCC。正是因?yàn)橛辛薓VCC，才造就了InnoDB強(qiáng)大的事務(wù)處理能力。
MVCC具體實(shí)現(xiàn)分析
InnoDB的MVCC,是通過在每行記錄后面保存兩個(gè)隱藏的列來實(shí)現(xiàn)的,這兩個(gè)列，分別保存了這個(gè)行的創(chuàng)建時(shí)間，一個(gè)保存的是行的刪除時(shí)間。這里存儲的并不是實(shí)際的時(shí)間值,而是系統(tǒng)版本號(可以理解為事務(wù)的ID)，每開始一個(gè)新的事務(wù)，系統(tǒng)版本號就會自動遞增，事務(wù)開始時(shí)刻的系統(tǒng)版本號會作為事務(wù)的ID.下面看一下在REPEATABLE READ隔離級別下,MVCC具體是如何操作的。
首先創(chuàng)建一張表:
- create table yang(
- id int primary key auto_increment,
- name varchar(20)
- );
假設(shè)系統(tǒng)的版本號從1開始.
INSERT
InnoDB為新插入的每一行保存當(dāng)前系統(tǒng)版本號作為版本號。***個(gè)事務(wù)ID為1:
- start transaction;
- insert into yang values(NULL,'yang');
- insert into yang values(NULL,'long');
- insert into yang values(NULL,'fei');
- commit;
對應(yīng)在數(shù)據(jù)中的表如下(后面兩列是隱藏列,我們通過查詢語句并看不到)
SELECT
InnoDB會根據(jù)以下兩個(gè)條件檢查每行記錄:
- InnoDB只會查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行(也就是,行的系統(tǒng)版本號小于或等于事務(wù)的系統(tǒng)版本號)，這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開始前已經(jīng)存在的，要么是事務(wù)自身插入或者修改過的.
- 行的刪除版本要么未定義,要么大于當(dāng)前事務(wù)版本號(這可以確保事務(wù)讀取到的行，在事務(wù)開始之前未被刪除)， 只有條件1、2同時(shí)滿足的記錄，才能返回作為查詢結(jié)果.
DELETE
InnoDB會為刪除的每一行保存當(dāng)前系統(tǒng)的版本號(事務(wù)的ID)作為刪除標(biāo)識.
看下面的具體例子分析: 第二個(gè)事務(wù),ID為2:
- start transaction;
- select * from yang;
- select * from yang;
- commit;
假設(shè)1:
假設(shè)在執(zhí)行這個(gè)事務(wù)ID為2的過程中,剛執(zhí)行到(1),這時(shí),有另一個(gè)事務(wù)ID為3往這個(gè)表里插入了一條數(shù)據(jù); 第三個(gè)事務(wù)ID為3;
- start transaction;
- insert into yang values(NULL,'tian');
- commit;
這時(shí)表中的數(shù)據(jù)如下:
然后接著執(zhí)行事務(wù)2中的(2),由于id=4的數(shù)據(jù)的創(chuàng)建時(shí)間(事務(wù)ID為3),執(zhí)行當(dāng)前事務(wù)的ID為2,而InnoDB只會查找事務(wù)ID小于等于當(dāng)前事務(wù)ID的數(shù)據(jù)行,所以id=4的數(shù)據(jù)行并不會在執(zhí)行事務(wù)2中的(2)被檢索出來,在事務(wù)2中的兩條select 語句檢索出來的數(shù)據(jù)如下:
假設(shè)2
假設(shè)在執(zhí)行這個(gè)事務(wù)ID為2的過程中,剛執(zhí)行到(1),假設(shè)事務(wù)執(zhí)行完事務(wù)3后，接著又執(zhí)行了事務(wù)4;
第四個(gè)事務(wù):
- start transaction;
- delete from yang where id=1;
- commit;
此時(shí)數(shù)據(jù)庫中的表如下:
接著執(zhí)行事務(wù)ID為2的事務(wù)(2),根據(jù)SELECT 檢索條件可以知道,它會檢索創(chuàng)建時(shí)間(創(chuàng)建事務(wù)的ID)小于當(dāng)前事務(wù)ID的行和刪除時(shí)間(刪除事務(wù)的ID)大于當(dāng)前事務(wù)的行,而id=4的行上面已經(jīng)說過,而id=1的行由于刪除時(shí)間(刪除事務(wù)的ID)大于當(dāng)前事務(wù)的ID,所以事務(wù)2的(2)select * from yang也會把id=1的數(shù)據(jù)檢索出來.所以,事務(wù)2中的兩條select 語句檢索出來的數(shù)據(jù)都如下:
UPDATE
InnoDB執(zhí)行UPDATE，實(shí)際上是新插入了一行記錄，并保存其創(chuàng)建時(shí)間為當(dāng)前事務(wù)的ID，同時(shí)保存當(dāng)前事務(wù)ID到要UPDATE的行的刪除時(shí)間。
假設(shè)3：
假設(shè)在執(zhí)行完事務(wù)2的(1)后又執(zhí)行,其它用戶執(zhí)行了事務(wù)3,4,這時(shí)，又有一個(gè)用戶對這張表執(zhí)行了UPDATE操作:
第5個(gè)事務(wù):
- start transaction;
- update yang set name='Long' where id=2;
- commit;
根據(jù)update的更新原則:會生成新的一行,并在原來要修改的列的刪除時(shí)間列上添加本事務(wù)ID,得到表如下:
繼續(xù)執(zhí)行事務(wù)2的(2),根據(jù)select 語句的檢索條件,得到下表:
還是和事務(wù)2中(1)select 得到相同的結(jié)果.
