本文意在弄清楚這些概念間的關系及其作用。弄清Mysql在開啟事務的情況下，每條sql執(zhí)行時的加鎖操作和MVCC版本控制。為使討論簡單，本文忽略了GAP鎖（間隙鎖、范圍鎖）。

我們經(jīng)常所高并發(fā)，高可用。就是從質(zhì)和量來評估，任何事物都可以從這兩個角度來分析。在Mysql數(shù)據(jù)庫中，事務就是用來保證質(zhì)的，MVCC就是用來保證量的。

事務

我們使用事務來保證每一條SQL語句的結(jié)果執(zhí)行符合我們的預期。我們說事務必須具備ACID特性。ACID中的三者：原子性、一致性和持久性其實描述的都差不多，保證SQL執(zhí)行結(jié)果的可靠性。而隔離性就比較復雜了，隔離性描述的是在并發(fā)場景下數(shù)據(jù)庫的表現(xiàn)，但并發(fā)量并不是固定的，而不同的業(yè)務可能有不同的需求，為了使數(shù)據(jù)庫能適應不同的并發(fā)場景，所以偉大的人們又定義了四種隔離級別：Read Uncommited，Read Committed (RC)，Repeatable Read (RR)，Serializable。隨著數(shù)據(jù)庫隔離級別的提高，數(shù)據(jù)的并發(fā)能力也有所下降。

隔離級別

標準隔離級別下數(shù)據(jù)庫會怎么表現(xiàn)可參考//m.survivalescaperooms.com/article/116477.htm，我們這里只討論共享鎖和排它鎖這兩概念，讀加共享鎖，寫加排它鎖：

在RC隔離級別下，修改數(shù)據(jù)會加排它鎖，事務結(jié)束釋放，其他事務不許讀，解決臟讀問題。（共享鎖當場釋放）
在RR隔離級別下，讀數(shù)據(jù)加共享鎖，事務結(jié)束釋放，其他事務不許修改，解決不可重復讀。（共享鎖事務結(jié)束釋放）

實際上都把操作串行化了。而Mysql對其進行了優(yōu)化，一個事務讀時其他事務不能寫，一個事務寫時其他事務不能讀？我不這么干照樣能解決臟讀和不可重復讀問題。MVCC出現(xiàn)了。（這也使得問題變得越來越復雜，而不一樣的地方也開始出現(xiàn)在RR隔離級別下，碰巧Mysql的默認隔離級別就是RR）

MVCC

MVCC即多版本并發(fā)控制，使用了雙版本號來解決數(shù)據(jù)的隔離問題。（“create”一個版本號，“delete”一個版本號，修改操作拆分為“delete”和“create”）每個事務在開始對每張表增刪改查操作時都會生成一個版本號，每個事務只能查到“create”小于本版本號和“delete”大于本版本號的數(shù)據(jù)。這樣，增刪查操作就完全可以并發(fā)進行了，只有修改操作是一定要排隊的。這樣，就算沒有共享鎖也解決了不可重復讀問題，因為其他事務修改后，數(shù)據(jù)的版本號比我大，我不會讀到。

MVCC在RR隔離級別下的并發(fā)

引入MVCC之后，看似很美好。然而大家有沒有想過兩個事務先后對一條數(shù)據(jù)做更新操作，然后兩個事務再讀取那條數(shù)據(jù)，分別讀到什么？哈哈，這根本是不可能出現(xiàn)的，因為修改操作是串行的，另一個事務必須先commit本事務才能修改。好，換個問題，兩個事務先后對一條數(shù)據(jù)做+1操作，另一個事務提交后，本事務再+1，再讀取那條數(shù)據(jù)，本事務是讀取到+1還是+2的結(jié)果？如果讀取到+2，那不是破壞了隔離性，讀到了其他事務提交的數(shù)據(jù)么？