面試官一口氣問了MySQL事務、鎖和MVCC,我


面試官你是怎么理解InnoDB引擎中的事務的?

候選者:在我的理解下,事務可以使「一組操作」要么全部成功,要么全部失敗

候選者:事務其目的是為了「保證數據最終的一致性」。

候選者:舉個例子,我給你發支付寶轉了888塊紅包。那自然我的支付寶余額會扣減888塊,你的支付寶余額會增加888塊。

候選者:而事務就是保證我的余額扣減跟你的余額增添是同時成功或者同時失敗的,這樣這次轉賬就正常了

面試官嗯,那你了解事務的幾大特性嗎?

候選者:嗯,就是ACID嘛,分別是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)。

候選者:原子性指的是:當前事務的操作要么同時成功,要么同時失敗。原子性由undo log日志來保證,因為undo log記載着數據修改前的信息。

候選者:比如我們要 insert 一條數據了,那undo log 會記錄的一條對應的 delete 日志。我們要 update 一條記錄時,那undo log會記錄之前的「舊值」的update記錄。

候選者:如果執行事務過程中出現異常的情況,那執行「回滾」。InnoDB引擎就是利用undo log記錄下的數據,來將數據「恢復」到事務開始之前

候選者:一致性我稍稍往后講,我先來說下隔離性

面試官:嗯...

候選者:隔離性指的是:在事務「並發」執行時,他們內部的操作不能互相干擾。如果多個事務可以同時操作一個數據,那么就會產生臟讀、重復讀、幻讀的問題。

候選者:於是,事務與事務之間需要存在「一定」的隔離。在InnoDB引擎中,定義了四種隔離級別供我們使用:

候選者:分別是:read uncommit(讀未提交)、read commit (讀已提交)、repeatable read (可重復復讀)、serializable (串行)

候選者:不同的隔離級別對事務之間的隔離性是不一樣的(級別越高事務隔離性越好,但性能就越低),而隔離性是由MySQL的各種鎖來實現的,只是它屏蔽了加鎖的細節。

候選者:持久性指的就是:一旦提交了事務,它對數據庫的改變就應該是永久性的。說白了就是,會將數據持久化在硬盤上。

候選者:而持久性由redo log 日志來保證,當我們要修改數據時,MySQL是先把這條記錄所在的「頁」找到,然后把該頁加載到內存中,將對應記錄進行修改。

候選者:為了防止內存修改完了,MySQL就掛掉了(如果內存改完,直接掛掉,那這次的修改相當於就丟失了)。

候選者:MySQL引入了redo log,內存寫完了,然后會寫一份redo log,這份redo log記載着這次在某個頁上做了什么修改。

候選者:即便MySQL在中途掛了,我們還可以根據redo log來對數據進行恢復。

候選者:redo log 是順序寫的,寫入速度很快。並且它記錄的是物理修改(xxxx頁做了xxx修改),文件的體積很小,恢復速度也很快。

候選者:回頭再來講一致性,「一致性」可以理解為我們使用事務的「目的」,而「隔離性」「原子性」「持久性」均是為了保障「一致性」的手段,保證一致性需要由應用程序代碼來保證

候選者:比如,如果事務在發生的過程中,出現了異常情況,此時你就得回滾事務,而不是強行提交事務來導致數據不一致。

面試官:嗯,挺好的,講了蠻多的

面試官:剛才你也提到了隔離性嘛,然后你說在MySQL中有四種隔離級別,能分別來介紹下嗎?

候選者:嗯,為了講清楚隔離級別,我順帶來說下MySQL鎖相關的知識吧。

候選者:在InnoDB引擎下,按鎖的粒度分類,可以簡單分為行鎖和表鎖。

候選者:行鎖實際上是作用在索引之上的(索引上次已經說過了,這里就不贅述了)。當我們的SQL命中了索引,那鎖住的就是命中條件內的索引節點(這種就是行鎖),如果沒有命中索引,那我們鎖的就是整個索引樹(表鎖)。

候選者:簡單來說就是:鎖住的是整棵樹還是某幾個節點,完全取決於SQL條件是否有命中到對應的索引節點。

候選者:而行鎖又可以簡單分為讀鎖(共享鎖、S鎖)和寫鎖(排它鎖、X鎖)。

候選者:讀鎖是共享的,多個事務可以同時讀取同一個資源,但不允許其他事務修改。寫鎖是排他的,寫鎖會阻塞其他的寫鎖和讀鎖。

候選者:我現在就再回到隔離級別上吧,就直接以例子來說明啦。

面試官:嗯...

候選者:首先來說下read uncommit(讀未提交)。比如說:A向B轉賬,A執行了轉賬語句,但A還沒有提交事務,B讀取數據,發現自己賬戶錢變多了!B跟A說,我已經收到錢了。A回滾事務【rollback】,等B再查看賬戶的錢時,發現錢並沒有多。

候選者:簡單的定義就是:事務B讀取到了事務A還沒提交的數據,這種用專業術語來說叫做「臟讀」。

候選者:對於鎖的維度而言,其實就是在read uncommit隔離級別下,讀不會加任何鎖,而寫會加排他鎖。讀什么鎖都不加,這就讓排他鎖無法排它了。

候選者:而我們又知道,對於更新操作而言,InnoDB是肯定會加寫鎖的(數據庫是不可能允許在同一時間,更新同一條記錄的)。而讀操作,如果不加任何鎖,那就會造成上面的臟讀。

候選者:臟讀在生產環境下肯定是無法接受的,那如果讀加鎖的話,那意味着:當更新數據的時,就沒辦法讀取了,這會極大地降低數據庫性能。

候選者:在MySQL InnoDB引擎層面,又有新的解決方案(解決加鎖后讀寫性能問題),叫做MVCC(Multi-Version Concurrency Control)多版本並發控制

候選者:在MVCC下,就可以做到讀寫不阻塞,且避免了類似臟讀這樣的問題。那MVCC是怎么做的呢?

候選者:MVCC通過生成數據快照(Snapshot),並用這個快照來提供一定級別(語句級或事務級)的一致性讀取

候選者:回到事務隔離級別下,針對於 read commit (讀已提交) 隔離級別,它生成的就是語句級快照,而針對於repeatable read (可重復讀),它生成的就是事務級的快照。

候選者:前面提到過read uncommit隔離級別下會產生臟讀,而read commit (讀已提交) 隔離級別解決了臟讀。思想其實很簡單:在讀取的時候生成一個"版本號",等到其他事務commit了之后,才會讀取最新已commit的"版本號"數據。

候選者:比如說:事務A讀取了記錄(生成版本號),事務B修改了記錄(此時加了寫鎖),事務A再讀取的時候,是依據最新的版本號來讀取的(當事務B執行commit了之后,會生成一個新的版本號),如果事務B還沒有commit,那事務A讀取的還是之前版本號的數據。

候選者:通過「版本」的概念,這樣就解決了臟讀的問題,而「版本」其實就是對應快照的數據。

候選者:read commit (讀已提交) 解決了臟讀,但也會有其他並發的問題。「不可重復讀」:一個事務讀取到另外一個事務已經提交的數據,也就是說一個事務可以看到其他事務所做的修改。

候選者:不可重復讀的例子:A查詢數據庫得到數據,B去修改數據庫的數據,導致A多次查詢數據庫的結果都不一樣【危害:A每次查詢的結果都是受B的影響的】

候選者:了解MVCC基礎之后,就很容易想到repeatable read (可重復復讀)隔離級別是怎么避免不可重復讀的問題了(前面也提到了)。

候選者:repeatable read (可重復復讀)隔離級別是「事務級別」的快照!每次讀取的都是「當前事務的版本」,即使當前數據被其他事務修改了(commit),也只會讀取當前事務版本的數據。

候選者:而repeatable read (可重復復讀)隔離級別會存在幻讀的問題,「幻讀」指的是指在一個事務內讀取到了別的事務插入的數據,導致前后讀取不一致。

候選者:在InnoDB引擎下的的repeatable read (可重復復讀)隔離級別下,快照讀MVCC影響下,已經解決了幻讀的問題(因為它是讀歷史版本的數據)

候選者:而如果是當前讀(指的是 select * from table for update),則需要配合間隙鎖來解決幻讀的問題。

候選者:剩下的就是serializable (串行)隔離級別了,它的最高的隔離級別,相當於不允許事務的並發,事務與事務之間執行是串行的,它的效率最低,但同時也是最安全的。

面試官:嗯,可以的。我看你提到了MVCC了,不妨來說下他的原理?

候選者:MVCC的主要是通過read view和undo log來實現的

候選者:undo log前面也提到了,它會記錄修改數據之前的信息,事務中的原子性就是通過undo log來實現的。所以,有undo log可以幫我們找到「版本」的數據

候選者:而read view 實際上就是在查詢時,InnoDB會生成一個read view,read view 有幾個重要的字段,分別是:trx_ids(尚未提交commit的事務版本號集合),low_limit_id(下一次要生成的事務ID值),low_limit_id(尚未提交版本號的事務ID最小值)以及creator_trx_id(當前的事務版本號)

候選者:在每行數據有兩列隱藏的字段,分別是DB_TRX_ID(記錄着當前ID)以及DB_ROLL_PTR(指向上一個版本數據在undo log 里的位置指針)

候選者:鋪墊到這了,很容易就發現,MVCC其實就是靠「比對版本」來實現讀寫不阻塞,而版本的數據存在於undo log中。

候選者:而針對於不同的隔離級別(read commit和repeatable read),無非就是read commit隔離級別下,每次都獲取一個新的read view,repeatable read隔離級別則每次事務只獲取一個read view

面試官:嗯,OK的。細節就不考究了,今天就到這里吧。

本文總結

  • 事務為了保證數據的最終一致性
  • 事務有四大特性,分別是原子性、一致性、隔離性、持久性
    • 原子性由undo log保證
    • 持久性由redo log 保證
    • 隔離性由數據庫隔離級別供我們選擇,分別有read uncommit,read commit,repeatable read,serializable
    • 一致性是事務的目的,一致性由應用程序來保證
  • 事務並發會存在各種問題,分別有臟讀、重復讀、幻讀問題。上面的不同隔離級別可以解決掉由於並發事務所造成的問題,而隔離級別實際上就是由MySQL鎖來實現的
  • 頻繁加鎖會導致數據庫性能低下,引入了MVCC多版本控制來實現讀寫不阻塞,提高數據庫性能
  • MVCC原理即通過read view 以及undo log來實現

歡迎關注我的微信公眾號【Java3y】來聊聊Java面試

【對線面試官-移動端】系列 一周兩篇持續更新中!

【對線面試官-電腦端】系列 一周兩篇持續更新中!

原創不易!!求三連!!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM