關(guān)于MVCC的原理，在《我想進(jìn)大廠》之mysql奪命連環(huán)13問寫過一次爆土，但是當(dāng)時(shí)寫的其實(shí)并不準(zhǔn)確椭懊，這個(gè)理解可以應(yīng)付面試，幫助快速理解步势，但是他的真正實(shí)現(xiàn)原理我想再次拿出來說一說氧猬。
簡(jiǎn)單理解版
以下先引用我之前寫過的那篇中的內(nèi)容，可以快速理解坏瘩，建議先簡(jiǎn)單看看盅抚。
要說幻讀，首先要了解MVCC倔矾，MVCC叫做多版本并發(fā)控制泉哈，實(shí)際上就是保存了數(shù)據(jù)在某個(gè)時(shí)間節(jié)點(diǎn)的快照。
我們每行數(shù)據(jù)實(shí)際上隱藏了兩列，創(chuàng)建時(shí)間版本號(hào)丛晦，過期(刪除)時(shí)間版本號(hào)，每開始一個(gè)新的事務(wù)提陶，版本號(hào)都會(huì)自動(dòng)遞增烫沙。
還是拿上面的user表舉例子，假設(shè)我們插入兩條數(shù)據(jù)隙笆，他們實(shí)際上應(yīng)該長(zhǎng)這樣锌蓄。
這時(shí)候假設(shè)小明去執(zhí)行查詢，此時(shí)current_version=3
select * from user where id<=3;
同時(shí)撑柔，小紅在這時(shí)候開啟事務(wù)去修改id=1的記錄瘸爽，current_version=4
update user set name='張三三' where id=1;
執(zhí)行成功后的結(jié)果是這樣的
如果這時(shí)候還有小黑在刪除id=2的數(shù)據(jù)，current_version=5铅忿，執(zhí)行后結(jié)果是這樣的剪决。
由于MVCC的原理是查找創(chuàng)建版本小于或等于當(dāng)前事務(wù)版本，刪除版本為空或者大于當(dāng)前事務(wù)版本檀训，小明的真實(shí)的查詢應(yīng)該是這樣
select * from user where id<=3 and create_version<=3 and (delete_version>3 or delete_version is null);
所以小明最后查詢到的id=1的名字還是'張三'柑潦，并且id=2的記錄也能查詢到。這樣做是為了保證事務(wù)讀取的數(shù)據(jù)是在事務(wù)開始前就已經(jīng)存在的峻凫，要么是事務(wù)自己插入或者修改的渗鬼。
真正原理
事實(shí)上，上述的說法只是簡(jiǎn)化版的理解荧琼，真正的MVCC用于讀已提交和可重復(fù)讀級(jí)別的控制譬胎，主要通過undo log日志版本鏈和read view來實(shí)現(xiàn)。
每條數(shù)據(jù)隱藏的兩個(gè)字段也并不是創(chuàng)建時(shí)間版本號(hào)和過期(刪除)時(shí)間版本號(hào)命锄，而是roll_pointer和trx_id堰乔。
roll_pointer指向更新事務(wù)之前生成的undo log，undo log用于事務(wù)的回滾累舷，保證事務(wù)的原子性浩考。
trx_id就是最近一次更新數(shù)據(jù)的事務(wù)ID。
以上述例子來舉例被盈，最初插入兩條數(shù)據(jù)析孽，真實(shí)的情況是這樣，因?yàn)榈谝淮尾迦霐?shù)據(jù)沒有undo log只怎，所以roll_pointer指向一個(gè)空的undo log袜瞬。
這時(shí)候假設(shè)小明去執(zhí)行查詢，就會(huì)開啟一個(gè)read view身堡，read view包含幾個(gè)重要的東西邓尤。
- m_ids，就是還未提交的事務(wù)id集合
- low_limit_id，m_ids里最小的值
- up_limit_id汞扎，下一次生成事務(wù)ID最大值
- creator_trx_id季稳，創(chuàng)建read view的事務(wù)ID，也就是自己的事務(wù)ID
小明來執(zhí)行查詢了澈魄，當(dāng)前事務(wù)ID=3
select * from user where id<=3;
小紅在這時(shí)候開啟事務(wù)去修改id=1的記錄景鼠，事務(wù)ID=4
update user set name='張三三' where id=1;
這時(shí)候小明的read view是這樣。
m_ids=[3,4]
low_limit_id=3
up_limit_id=5
creator_trx_id=3
所以痹扇，小明在執(zhí)行查詢的時(shí)候铛漓，會(huì)去判斷當(dāng)前這條數(shù)據(jù)的trx_id<read view的low_limit_id，顯然都小于鲫构，所以小明會(huì)正常查詢到id=1,2的兩條記錄浓恶，而不會(huì)受到小紅修改的影響。
這時(shí)候结笨，小紅的修改也完成了包晰，小紅數(shù)據(jù)于是就變成了這樣。
如果小明再次去查詢的話禀梳，就會(huì)發(fā)現(xiàn)現(xiàn)在的trx_id>read view的low_limit_id杜窄，也就是4>3，不符合條件算途，同時(shí)發(fā)現(xiàn)現(xiàn)在的trx_id=4在low_limit_id和up_limit_id [3,5]之間塞耕，并且trx_id=4在m_ids=[3,4]之中，所以就會(huì)根據(jù)roll_pointer指向的undo log去查找嘴瓤，trx_id=1小于現(xiàn)在的low_limit_id=3扫外，符合條件，就找到了上一個(gè)版本name=張三的記錄廓脆。
如果這時(shí)候小明自己去修改這條記錄的值筛谚，把名字改成張五，結(jié)果就是這樣停忿。
然后小明去查詢的話驾讲，就會(huì)發(fā)現(xiàn)當(dāng)前的trx_id=3就是自己的creator_trx_id，就是自己席赂，那么就直接返回這條數(shù)據(jù)吮铭。
所以，我們可以先總結(jié)下幾種情況：
- 如果trx_id<low_limit_id颅停，那么說明就是之前事務(wù)的數(shù)據(jù)谓晌，直接返回，也就對(duì)應(yīng)了小明第一次開啟事務(wù)查詢的場(chǎng)景
- 如果trx_id>low_limit癞揉，trx_id還在[low_limit_id,up_limit_id]范圍之內(nèi)纸肉，并且trx_id在m_ids中溺欧，就會(huì)根據(jù)roll_pointer去查找undo log日志鏈，找到之前版本的數(shù)據(jù)柏肪，對(duì)應(yīng)的就是小紅修改后小明再次查詢的場(chǎng)景
- 如果trx_id=creator_trx_id姐刁，那么說明就是自己修改的，直接返回就好了烦味，對(duì)應(yīng)的就是小明自己去修改數(shù)據(jù)的場(chǎng)景
不同隔離級(jí)別的實(shí)現(xiàn)
根據(jù)上面闡述的原理龙填，你可能發(fā)現(xiàn)了，這是可重復(fù)讀下的實(shí)現(xiàn)啊拐叉，保證每次讀取到的數(shù)據(jù)都是一致的。
那么扇商，如果是讀已提交級(jí)別下凤瘦，這個(gè)是怎么實(shí)現(xiàn)的？
其實(shí)很簡(jiǎn)單案铺，在上面的原理解釋中蔬芥，我都是假設(shè)每次查詢的時(shí)候生成了read view，后續(xù)并沒有重新生成控汉。
而讀已提交級(jí)別下笔诵，則是每次查詢都會(huì)生成一次read view。
以上述小紅修改過張三后的場(chǎng)景來舉例姑子。
在可重復(fù)度級(jí)別下乎婿，由于trx_id>low_limit，trx_id還在[low_limit_id,up_limit_id]范圍之內(nèi)街佑，并且trx_id在m_ids中谢翎，滿足我們上述的條件2，所以就會(huì)根據(jù)roll_pointer找到之前的版本記錄沐旨，保證可重復(fù)讀森逮。
而在讀已提交的級(jí)別下，重新生成了read view磁携，這時(shí)候trx_id不在m_ids之中褒侧，說明事務(wù)已經(jīng)提交，所以可以直接返回這條數(shù)據(jù)谊迄，所以查到的數(shù)據(jù)就是小紅修改后的name=張三三的數(shù)據(jù)了闷供。
總結(jié)
我是艾小仙，我承認(rèn)我浪了鳞上，我之前居然還想浪这吻，我以為年沒過幾天，結(jié)果發(fā)現(xiàn)最近一次技術(shù)文更新是在2月2號(hào)篙议。
我哭唾糯，所以怠硼，我肝了3個(gè)小時(shí)，痛定思痛移怯，結(jié)束了我的短暫的王者生涯香璃。
大家覺得還行的話，點(diǎn)個(gè)在看舟误，設(shè)個(gè)星標(biāo)可好葡秒？
我要回到正常更新的頻率中來。
