《對線面試官》 MySQL 事務(wù)、鎖和MVCC
面試官：你是怎么理解InnoDB引擎中的事務(wù)的？
候選者：在我的理解下，事務(wù)可以使「一組操作」要么全部成功，要么全部失敗
候選者：事務(wù)其目的是為了「保證數(shù)據(jù)最終的一致性」。
候選者：舉個例子，我給你發(fā)支付寶轉(zhuǎn)了888塊紅包。那自然我的支付寶余額會扣減888塊，你的支付寶余額會增加888塊。
候選者：而事務(wù)就是保證我的余額扣減跟你的余額增添是同時成功或者同時失敗的，這樣這次轉(zhuǎn)賬就正常了
面試官：嗯，那你了解事務(wù)的幾大特性嗎？
候選者：嗯，就是ACID嘛，分別是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
候選者：原子性指的是：當前事務(wù)的操作要么同時成功，要么同時失敗。原子性由undo log日志來保證，因為undo log記載著數(shù)據(jù)修改前的信息。
候選者：比如我們要 insert 一條數(shù)據(jù)了，那undo log 會記錄的一條對應(yīng)的 delete 日志。我們要 update 一條記錄時，那undo log會記錄之前的「舊值」的update記錄。
候選者：如果執(zhí)行事務(wù)過程中出現(xiàn)異常的情況，那執(zhí)行「回滾」。InnoDB引擎就是利用undo log記錄下的數(shù)據(jù)，來將數(shù)據(jù)「恢復(fù)」到事務(wù)開始之前
候選者：一致性我稍稍往后講，我先來說下隔離性
面試官：嗯…
候選者：隔離性指的是：在事務(wù)「并發(fā)」執(zhí)行時，他們內(nèi)部的操作不能互相干擾。如果多個事務(wù)可以同時操作一個數(shù)據(jù)，那么就會產(chǎn)生臟讀、重復(fù)讀、幻讀的問題。
候選者：于是，事務(wù)與事務(wù)之間需要存在「一定」的隔離。在InnoDB引擎中，定義了四種隔離級別供我們使用：
候選者：分別是：read uncommit(讀未提交)、read commit (讀已提交)、repeatable read (可重復(fù)復(fù)讀)、serializable (串行)
候選者：不同的隔離級別對事務(wù)之間的隔離性是不一樣的（級別越高事務(wù)隔離性越好，但性能就越低），而隔離性是由MySQL的各種鎖來實現(xiàn)的，只是它屏蔽了加鎖的細節(jié)。
候選者：持久性指的就是：一旦提交了事務(wù)，它對數(shù)據(jù)庫的改變就應(yīng)該是永久性的。說白了就是，會將數(shù)據(jù)持久化在硬盤上。
候選者：而持久性由redo log 日志來保證，當我們要修改數(shù)據(jù)時，MySQL是先把這條記錄所在的「頁」找到，然后把該頁加載到內(nèi)存中，將對應(yīng)記錄進行修改。
候選者：為了防止內(nèi)存修改完了，MySQL就掛掉了（如果內(nèi)存改完，直接掛掉，那這次的修改相當于就丟失了）。
候選者：MySQL引入了redo log，內(nèi)存寫完了，然后會寫一份redo log，這份redo log記載著這次在某個頁上做了什么修改。
候選者：即便MySQL在中途掛了，我們還可以根據(jù)redo log來對數(shù)據(jù)進行恢復(fù)。
候選者：redo log 是順序?qū)懙模瑢懭胨俣群芸臁２⑶宜涗浀氖俏锢硇薷模▁xxx頁做了xxx修改），文件的體積很小，恢復(fù)速度也很快。
候選者：回頭再來講一致性，「一致性」可以理解為我們使用事務(wù)的「目的」，而「隔離性」「原子性」「持久性」均是為了保障「一致性」的手段，保證一致性需要由應(yīng)用程序代碼來保證
候選者：比如，如果事務(wù)在發(fā)生的過程中，出現(xiàn)了異常情況，此時你就得回滾事務(wù)，而不是強行提交事務(wù)來導(dǎo)致數(shù)據(jù)不一致。
面試官：嗯，挺好的，講了蠻多的
面試官：剛才你也提到了隔離性嘛，然后你說在MySQL中有四種隔離級別，能分別來介紹下嗎？
候選者：嗯，為了講清楚隔離級別，我順帶來說下MySQL鎖相關(guān)的知識吧。
候選者：在InnoDB引擎下，按鎖的粒度分類，可以簡單分為行鎖和表鎖。
候選者：行鎖實際上是作用在索引之上的（索引上次已經(jīng)說過了，這里就不贅述了）。當我們的SQL命中了索引，那鎖住的就是命中條件內(nèi)的索引節(jié)點（這種就是行鎖），如果沒有命中索引，那我們鎖的就是整個索引樹（表鎖）。
候選者：簡單來說就是：鎖住的是整棵樹還是某幾個節(jié)點，完全取決于SQL條件是否有命中到對應(yīng)的索引節(jié)點。
候選者：而行鎖又可以簡單分為讀鎖（共享鎖、S鎖）和寫鎖（排它鎖、X鎖）。
候選者：讀鎖是共享的，多個事務(wù)可以同時讀取同一個資源，但不允許其他事務(wù)修改。寫鎖是排他的，寫鎖會阻塞其他的寫鎖和讀鎖。
候選者：我現(xiàn)在就再回到隔離級別上吧，就直接以例子來說明啦。
面試官：嗯…
候選者：首先來說下read uncommit(讀未提交)。比如說：A向B轉(zhuǎn)賬，A執(zhí)行了轉(zhuǎn)賬語句，但A還沒有提交事務(wù)，B讀取數(shù)據(jù)，發(fā)現(xiàn)自己賬戶錢變多了！B跟A說，我已經(jīng)收到錢了。A回滾事務(wù)【rollback】，等B再查看賬戶的錢時，發(fā)現(xiàn)錢并沒有多。
候選者：簡單的定義就是：事務(wù)B讀取到了事務(wù)A還沒提交的數(shù)據(jù)，這種用專業(yè)術(shù)語來說叫做「臟讀」。
候選者：對于鎖的維度而言，其實就是在read uncommit隔離級別下，讀不會加任何鎖，而寫會加排他鎖。讀什么鎖都不加，這就讓排他鎖無法排它了。
候選者：而我們又知道，對于更新操作而言，InnoDB是肯定會加寫鎖的（數(shù)據(jù)庫是不可能允許在同一時間，更新同一條記錄的）。而讀操作，如果不加任何鎖，那就會造成上面的臟讀。
候選者：臟讀在生產(chǎn)環(huán)境下肯定是無法接受的，那如果讀加鎖的話，那意味著：當更新數(shù)據(jù)的時，就沒辦法讀取了，這會極大地降低數(shù)據(jù)庫性能。
候選者：在MySQL InnoDB引擎層面，又有新的解決方案（解決加鎖后讀寫性能問題），叫做MVCC(Multi-Version Concurrency Control)多版本并發(fā)控制
候選者：在MVCC下，就可以做到讀寫不阻塞，且避免了類似臟讀這樣的問題。那MVCC是怎么做的呢？
候選者：MVCC通過生成數(shù)據(jù)快照（Snapshot)，并用這個快照來提供一定級別（語句級或事務(wù)級）的一致性讀取
候選者：回到事務(wù)隔離級別下，針對于 read commit (讀已提交) 隔離級別，它生成的就是語句級快照，而針對于repeatable read (可重復(fù)讀)，它生成的就是事務(wù)級的快照。
候選者：前面提到過read uncommit隔離級別下會產(chǎn)生臟讀，而read commit (讀已提交) 隔離級別解決了臟讀。思想其實很簡單：在讀取的時候生成一個”版本號”，等到其他事務(wù)commit了之后，才會讀取最新已commit的”版本號”數(shù)據(jù)。
候選者：比如說：事務(wù)A讀取了記錄(生成版本號)，事務(wù)B修改了記錄(此時加了寫鎖)，事務(wù)A再讀取的時候，是依據(jù)最新的版本號來讀取的(當事務(wù)B執(zhí)行commit了之后，會生成一個新的版本號)，如果事務(wù)B還沒有commit，那事務(wù)A讀取的還是之前版本號的數(shù)據(jù)。
候選者：通過「版本」的概念，這樣就解決了臟讀的問題，而「版本」其實就是對應(yīng)快照的數(shù)據(jù)。
候選者：read commit (讀已提交) 解決了臟讀，但也會有其他并發(fā)的問題。「不可重復(fù)讀」：一個事務(wù)讀取到另外一個事務(wù)已經(jīng)提交的數(shù)據(jù)，也就是說一個事務(wù)可以看到其他事務(wù)所做的修改。
候選者：不可重復(fù)讀的例子：A查詢數(shù)據(jù)庫得到數(shù)據(jù)，B去修改數(shù)據(jù)庫的數(shù)據(jù)，導(dǎo)致A多次查詢數(shù)據(jù)庫的結(jié)果都不一樣【危害：A每次查詢的結(jié)果都是受B的影響的】
候選者：了解MVCC基礎(chǔ)之后，就很容易想到repeatable read (可重復(fù)復(fù)讀)隔離級別是怎么避免不可重復(fù)讀的問題了（前面也提到了）。
候選者：repeatable read (可重復(fù)復(fù)讀)隔離級別是「事務(wù)級別」的快照！每次讀取的都是「當前事務(wù)的版本」，即使當前數(shù)據(jù)被其他事務(wù)修改了(commit)，也只會讀取當前事務(wù)版本的數(shù)據(jù)。
候選者：而repeatable read (可重復(fù)復(fù)讀)隔離級別會存在幻讀的問題，「幻讀」指的是指在一個事務(wù)內(nèi)讀取到了別的事務(wù)插入的數(shù)據(jù)，導(dǎo)致前后讀取不一致。
候選者：在InnoDB引擎下的的repeatable read (可重復(fù)復(fù)讀)隔離級別下，快照讀MVCC影響下，已經(jīng)解決了幻讀的問題（因為它是讀歷史版本的數(shù)據(jù)）
候選者：而如果是當前讀（指的是 select * from table for update），則需要配合間隙鎖來解決幻讀的問題。
候選者：剩下的就是serializable (串行)隔離級別了，它的最高的隔離級別，相當于不允許事務(wù)的并發(fā)，事務(wù)與事務(wù)之間執(zhí)行是串行的，它的效率最低，但同時也是最安全的。
面試官：嗯，可以的。我看你提到了MVCC了，不妨來說下他的原理？
候選者：MVCC的主要是通過read view和undo log來實現(xiàn)的
候選者：undo log前面也提到了，它會記錄修改數(shù)據(jù)之前的信息，事務(wù)中的原子性就是通過undo log來實現(xiàn)的。所以，有undo log可以幫我們找到「版本」的數(shù)據(jù)
候選者：而read view 實際上就是在查詢時，InnoDB會生成一個read view，read view 有幾個重要的字段，分別是：trx_ids（尚未提交commit的事務(wù)版本號集合），up_limit_id（下一次要生成的事務(wù)ID值），low_limit_id（尚未提交版本號的事務(wù)ID最小值）以及creator_trx_id（當前的事務(wù)版本號）
候選者：在每行數(shù)據(jù)有兩列隱藏的字段，分別是DB_TRX_ID（記錄著當前ID）以及DB_ROLL_PTR（指向上一個版本數(shù)據(jù)在undo log 里的位置指針）
候選者：鋪墊到這了，很容易就發(fā)現(xiàn)，MVCC其實就是靠「比對版本」來實現(xiàn)讀寫不阻塞，而版本的數(shù)據(jù)存在于undo log中。
候選者：而針對于不同的隔離級別（read commit和repeatable read），無非就是read commit隔離級別下，每次都獲取一個新的read view，repeatable read隔離級別則每次事務(wù)只獲取一個read view
面試官：嗯，OK的。細節(jié)就不考究了，今天就到這里吧。
本文總結(jié)：
事務(wù)為了保證數(shù)據(jù)的最終一致性
事務(wù)有四大特性，分別是原子性、一致性、隔離性、持久性
原子性由undo log保證 持久性由redo log 保證 隔離性由數(shù)據(jù)庫隔離級別供我們選擇，分別有read uncommit,read commit,repeatable read,serializable 一致性是事務(wù)的目的，一致性由應(yīng)用程序來保證 事務(wù)并發(fā)會存在各種問題，分別有臟讀、重復(fù)讀、幻讀問題。上面的不同隔離級別可以解決掉由于并發(fā)事務(wù)所造成的問題，而隔離級別實際上就是由MySQL鎖來實現(xiàn)的
頻繁加鎖會導(dǎo)致數(shù)據(jù)庫性能低下，引入了MVCC多版本控制來實現(xiàn)讀寫不阻塞，提高數(shù)據(jù)庫性能
MVCC原理即通過read view 以及undo log來實現(xiàn)