1、MVCC簡(jiǎn)介
1.1 什么是MVCC
MVCC(全稱Multi-Version Concurrent Control)是一種多版本并發(fā)控制機(jī)制。
1.2 MVCC是為了解決什么問題
- 大多數(shù)MYSQL事務(wù)型存儲(chǔ)引擎，如InnoDB, Falcon以及PBXT都不使用一種簡(jiǎn)單的行鎖機(jī)制。事實(shí)上，他們都和MVCC多版本控制一起來(lái)使用。
- 鎖機(jī)制可以控制并發(fā)操作，但是其系統(tǒng)開銷較大，而MVCC可以在大多數(shù)情況下代替行級(jí)鎖，使用MVCC能降低其系統(tǒng)開銷。
1.3 MVCC實(shí)現(xiàn)
MVCC是通過保存數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)的快照來(lái)實(shí)現(xiàn)的。不同存儲(chǔ)引擎的MVCC實(shí)現(xiàn)不同，典型的有樂觀并發(fā)控制和悲觀并發(fā)開銷。
2、MVCC 具體實(shí)現(xiàn)
Innodb的MVCC是通過在每行記錄后面保存兩個(gè)隱藏的列來(lái)實(shí)現(xiàn)的。這兩個(gè)列，一個(gè)保存了這個(gè)行的創(chuàng)建時(shí)間，另一個(gè)保存的是行的刪除時(shí)間。這里存儲(chǔ)的并不是實(shí)際的時(shí)間值，而是系統(tǒng)版本號(hào)，每開始一個(gè)新的事務(wù)，系統(tǒng)版本號(hào)就會(huì)自動(dòng)遞增，事務(wù)開始時(shí)刻的系統(tǒng)版本號(hào)會(huì)作為事務(wù)的ID。下面看一下在REPEATABLE READ 隔離級(jí)別下，MVCC具體是如何操作的。
2.1 簡(jiǎn)單的例子
create table user (
uid int primary key auto_increment,
name varchar(20));
- INSERT
InnoDB為新插入的每一行保存當(dāng)前系統(tǒng)版本號(hào)作為版本號(hào)。假設(shè)系統(tǒng)的版本號(hào)從1開始，第一個(gè)事務(wù)ID為1.
start transaction;
insert into user values(NULL, 'Hans');
insert into user values(NULL, 'Will');
insert into user values(NULL, 'Jack');
commit;
對(duì)應(yīng)的數(shù)據(jù)中的表如下（后面兩列隱藏，我們通過查詢語(yǔ)句看不到）
| uid | name | 創(chuàng)建時(shí)間（事務(wù)ID） | 刪除時(shí)間（事務(wù)ID） |
|---|---|---|---|
| 1 | Hans | 1 | undefined |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
SELECT
InnoDB會(huì)根據(jù)以下兩個(gè)條件檢查每行記錄，查詢結(jié)果必須同時(shí)滿足這兩個(gè)條件。
1、InnoDB只會(huì)查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行（即行的系統(tǒng)版本號(hào)小于或等于事務(wù)的系統(tǒng)版本號(hào)），這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開始前已經(jīng)存在，要么是事務(wù)自身插入或修改過。
2、行的刪除版本要么未定義，要么大于當(dāng)前事務(wù)版本號(hào)，這可以確保事務(wù)讀取到的行，在事務(wù)開始之前未被刪除。DELETE
InnoDB會(huì)為刪除的每一行保存當(dāng)前系統(tǒng)的版本號(hào)（事務(wù)的ID）作為刪除標(biāo)識(shí)。
第二個(gè)事務(wù)，ID為2
start transaction;
select * from user; //(s 1)
select * from user; //(s 2)
commit;
假設(shè)1
假設(shè)在執(zhí)行這個(gè)事務(wù)ID 為2的過程中，剛執(zhí)行到（s 1），這時(shí)，有另一個(gè)事務(wù)ID為3往這個(gè)表里插入了一條數(shù)據(jù)；
start transaction;
insert into user values(NULL, 'Charles');
commit;
這時(shí)表中數(shù)據(jù)如下：
| uid | name | 創(chuàng)建時(shí)間() | 刪除時(shí)間() |
|---|---|---|---|
| 1 | Hans | 1 | undefined |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
由于user表uid=4的數(shù)據(jù)創(chuàng)建時(shí)間事務(wù)ID為3，執(zhí)行當(dāng)前事務(wù)的ID為2，而InnoDB只會(huì)查找事務(wù)ID小于等于當(dāng)前事務(wù)ID的數(shù)據(jù)行，所以u(píng)id=4的數(shù)據(jù)在執(zhí)行事務(wù)2中的（s 2）時(shí)不會(huì)被檢索出來(lái)。
假設(shè)2
假設(shè)子啊執(zhí)行事務(wù)ID為2的過程中，剛執(zhí)行到(s 1)，事務(wù)執(zhí)行完事務(wù)3后，有執(zhí)行事務(wù)4：
start transaction;
delete from user where id=1;
commit;
此時(shí)數(shù)據(jù)表如下：
| uid | name | 創(chuàng)建時(shí)間() | 刪除時(shí)間() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
接著執(zhí)行事務(wù)ID為2的事務(wù)(s 2)，根據(jù)select檢索條件知道，它只會(huì)檢索創(chuàng)建時(shí)間小于當(dāng)前事務(wù)ID和刪除時(shí)間大于當(dāng)前事務(wù)的行。檢索出數(shù)據(jù)如下：
| uid | name | 創(chuàng)建時(shí)間() | 刪除時(shí)間() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | undefined |
| 3 | Jack | 1 | undefined |
- 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的(s 1)后，其他用戶執(zhí)行了事務(wù)3，4，又有一個(gè)用戶對(duì)這張表執(zhí)行了UPDATE的操作：
第5個(gè)事務(wù)：
start transaction;
update user set name='Jucy' where id=2;
commit;
得到如下表：
| uid | name | 創(chuàng)建時(shí)間() | 刪除時(shí)間() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | 5 |
| 3 | Jack | 1 | undefined |
| 4 | Charles | 3 | undefined |
| 2 | Jucy | 5 | undefined |
繼續(xù)執(zhí)行事務(wù)2的(s 2)，會(huì)得到如下表
| uid | name | 創(chuàng)建時(shí)間() | 刪除時(shí)間() |
|---|---|---|---|
| 1 | Hans | 1 | 4 |
| 2 | Will | 1 | 5 |
| 3 | Jack | 1 | undefined |
