底層原理：redo log、undo log、MVCC與鎖機(jī)制全解析)
前幾天我一個(gè)朋友去面某廠的Java后端崗被問到“MySQL事務(wù)的底層原理是什么”他說自己當(dāng)時(shí)腦子里蹦出來的只有ACID四個(gè)字母其他的什么redo log、undo log、MVCC、間隙鎖全卡殼了。這個(gè)問題我去面別人的時(shí)候也喜歡問倒不是為了刁難人而是它真的很能區(qū)分一個(gè)人是背過八股還是真把數(shù)據(jù)庫搞通過。MySQL事務(wù)這塊的知識(shí)點(diǎn)是隔離級(jí)別、日志機(jī)制、索引結(jié)構(gòu)、并發(fā)控制、甚至Spring事務(wù)管理的交匯點(diǎn)你把這一條線理清了數(shù)據(jù)庫這塊的面試基本就穩(wěn)了一大半。這篇文章我按我自己做面試復(fù)盤的習(xí)慣來寫把MySQL事務(wù)底層原理拆成六塊先講事務(wù)解決什么問題再講redo log、undo log、binlog三大日志然后是MVCC和ReadView接著是鎖和幻讀的解法最后補(bǔ)上長事務(wù)、Spring事務(wù)失效這些高頻追問以及一份可以直接背的面試速查。適合準(zhǔn)備秋招春招的Java后端、需要梳理知識(shí)體系的MySQL使用者還有那些“用事務(wù)用了好幾年但說不清原理”的工程師。1. 先弄明白事務(wù)到底在解決什么問題1.1 從一個(gè)經(jīng)典的扣款場景說起講事務(wù)原理之前先想一個(gè)每個(gè)后端都寫過的代碼轉(zhuǎn)賬。A賬戶扣100塊B賬戶加100塊。如果扣完A的錢之后系統(tǒng)突然斷電了B的錢沒加這錢就憑空消失了。業(yè)務(wù)上絕對不允許這種狀態(tài)出現(xiàn)所以我們要把“扣A”和“加B”綁成一個(gè)整體要么都成功要么都失敗——這個(gè)“整體”就是事務(wù)。但事務(wù)不是只解決“全成功或全失敗”這一個(gè)問題。你在高并發(fā)場景下還會(huì)遇到別的麻煩兩個(gè)用戶同時(shí)讀同一個(gè)數(shù)據(jù)一個(gè)改了另一個(gè)還在用舊值一個(gè)事務(wù)在統(tǒng)計(jì)總額另一個(gè)事務(wù)在瘋狂插入新訂單統(tǒng)計(jì)結(jié)果一會(huì)兒多一條一會(huì)兒少一條兩個(gè)人同時(shí)改同一行數(shù)據(jù)最后誰覆蓋誰……這些問題事務(wù)都要管。所以數(shù)據(jù)庫的事務(wù)機(jī)制本質(zhì)上是應(yīng)對四類問題的工具原子性管“要么全做要么全不做”一致性管“數(shù)據(jù)永遠(yuǎn)滿足業(yè)務(wù)規(guī)則”隔離性管“并發(fā)事務(wù)之間互不干擾”持久性管“數(shù)據(jù)提交了就不會(huì)丟”。這四件事看著抽象底層都有實(shí)打?qū)嵉臋C(jī)制在支撐后面幾節(jié)我會(huì)一個(gè)個(gè)對應(yīng)著講。1.2 ACID四兄弟各自的底層靠山很多人背ACID就是背字母面試被追問一句“原子性靠什么實(shí)現(xiàn)”就啞火了。這里給你一張對照表把四兄弟和底層機(jī)制對應(yīng)起來ACID特性解決什么問題底層核心機(jī)制原子性 Atomicity事務(wù)內(nèi)操作要么全成功要么全回滾undo log回滾日志一致性 Consistency數(shù)據(jù)在事務(wù)前后滿足約束和業(yè)務(wù)規(guī)則應(yīng)用代碼 數(shù)據(jù)庫約束 其他三個(gè)特性共同保證隔離性 Isolation并發(fā)事務(wù)不互相干擾鎖機(jī)制 MVCC多版本并發(fā)控制持久性 Durability事務(wù)提交后數(shù)據(jù)不丟失redo log重做日志 binlog注意一致性跟前三個(gè)不一樣它不是一個(gè)獨(dú)立的機(jī)制更像是“目的”。原子性、隔離性、持久性都做到了一致性這個(gè)結(jié)果自然就有了。比如轉(zhuǎn)賬場景只要原子性保證了扣款和加款同時(shí)成功或同時(shí)失敗賬就是平的一致性就滿足了。但有些一致性靠數(shù)據(jù)庫管不了比如“庫存不能為負(fù)數(shù)”你得在業(yè)務(wù)代碼里判斷或者建一個(gè)CHECK約束數(shù)據(jù)庫沒有義務(wù)替你想業(yè)務(wù)規(guī)則。面試官如果問“ACID分別靠什么實(shí)現(xiàn)”你就說原子性靠undo log回滾持久性靠redo log和binlog隔離性靠鎖和MVCC一致性是前三者共同作用的結(jié)果。這個(gè)答案一句話就把后面所有細(xì)節(jié)串起來了。2. 三大日志redo log、undo log、binlog底層持久化的命根子2.1 redo log為什么必須存在隨機(jī)寫和順序?qū)懙牟顒e先問一個(gè)問題InnoDB的數(shù)據(jù)是存在哪里的存在磁盤上的B樹索引文件里這個(gè)沒問題。但你要知道你執(zhí)行一條UPDATE語句InnoDB不是馬上去改磁盤上那個(gè)B樹頁里的數(shù)據(jù)因?yàn)榇疟P隨機(jī)讀寫太慢了。它是先把對應(yīng)的數(shù)據(jù)頁加載到內(nèi)存的Buffer Pool里在內(nèi)存里改掉然后事務(wù)提交的時(shí)候就把這個(gè)修改記錄到redo log里redo log是順序追加寫的比隨機(jī)寫快幾個(gè)數(shù)量級(jí)。之后系統(tǒng)會(huì)在某個(gè)合適的時(shí)間再把內(nèi)存里的臟頁刷回磁盤。這就是WAL機(jī)制Write-Ahead Logging先寫日志再寫數(shù)據(jù)。為什么要這么設(shè)計(jì)生活化類比一下你開了個(gè)飯店每天的流水很大每來一桌客人都把賬本翻出來改會(huì)很慢你也怕客人走了忘記。所以你先在一個(gè)小本子上按順序記“今天第幾桌點(diǎn)了什么菜花了多少錢”晚上打烊了再慢慢把它謄寫到正式賬本上。萬一中途停電了你手上的小本子還在賬就不會(huì)丟。redo log有兩個(gè)關(guān)鍵特性它是物理日志記錄的是“某個(gè)頁的某個(gè)偏移量改成了什么值”而不是“執(zhí)行了什么SQL”所以恢復(fù)速度很快它的文件是固定大小、循環(huán)寫的寫滿了會(huì)觸發(fā)checkpoint把臟頁刷盤、推進(jìn)LSN日志序列號(hào)然后把舊日志覆蓋掉。redo log的“重做”能力就是崩潰恢復(fù)時(shí)把那些已經(jīng)提交但還沒來得及刷盤的數(shù)據(jù)頁重新應(yīng)用一遍日志保證不會(huì)丟已提交的事務(wù)。這也正是持久性的核心。2.2 undo log回滾和MVCC版本鏈的起點(diǎn)redo log負(fù)責(zé)“重做”undo log正好相反負(fù)責(zé)“撤銷”。事務(wù)執(zhí)行過程中每改一行數(shù)據(jù)InnoDB都會(huì)記一條undo log里面保存的是這行數(shù)據(jù)修改前的樣子。事務(wù)回滾的時(shí)候就拿著undo log把數(shù)據(jù)改回去。舉個(gè)簡潔的例子事務(wù)T1執(zhí)行UPDATE user SET age 30 WHERE id 1原來age是20。InnoDB會(huì)先寫一條undo logid1這行原來的age20然后才把a(bǔ)ge改成30。如果T1要回滾就根據(jù)這條undo log把a(bǔ)ge改回20。但undo log的作用不止回滾它還是MVCC的地基。每一行數(shù)據(jù)上都會(huì)有一個(gè)隱藏的DB_ROLL_PTR字段指向它上一個(gè)版本的undo log這樣多個(gè)版本的數(shù)據(jù)就串成了一條“版本鏈”。后面講MVCC時(shí)你會(huì)看到這條版本鏈就是事務(wù)判斷“哪個(gè)版本對我來說可見”的關(guān)鍵。另外有個(gè)很多人忽略的細(xì)節(jié)undo log也是要持久化的它也要寫redo log因?yàn)槿绻罎⒘藘?nèi)存里的undo信息丟了沒有redo的話連回滾都做不了。這個(gè)點(diǎn)面試不常見但提出來會(huì)顯得你確實(shí)讀過源碼層面的東西。2.3 binlog 兩階段提交主從復(fù)制和數(shù)據(jù)一致性的保障redo log是InnoDB存儲(chǔ)引擎層的日志binlog則是MySQL Server層的日志。redo log記錄頁級(jí)物理修改binlog記錄的是邏輯SQL或者說“做了什么變更”并且binlog是追加寫的不會(huì)覆蓋所以它才是主從復(fù)制和數(shù)據(jù)恢復(fù)的主角從庫拿到binlog在本地重放一遍就變成了主庫的樣子。但這就有個(gè)嚴(yán)重問題redo log是引擎層的binlog是Server層的兩層日志各自寫各自的萬一寫完還沒寫完就崩了數(shù)據(jù)就不一致了。比如主庫redo log里已經(jīng)標(biāo)記事務(wù)提交了但binlog還沒來得及寫這時(shí)候從庫同步不到這條變更主從就亂了。解決辦法是兩階段提交事務(wù)提交時(shí)先寫redo log并標(biāo)記為prepare狀態(tài)然后寫binlog最后再把redo log標(biāo)記為commit狀態(tài)。崩潰恢復(fù)時(shí)MySQL會(huì)檢查所有狀態(tài)為prepare的redo log看對應(yīng)的binlog是否完整如果binlog完整就判定事務(wù)可以提交補(bǔ)一條commit如果binlog不完整就回滾這個(gè)事務(wù)。因?yàn)閎inlog寫完整的那一刻主從才能拿到一致的數(shù)據(jù)。這個(gè)設(shè)計(jì)保證了引擎日志和Server日志的最終一致也是面試?yán)铩癲istributed transaction的Mini版”——兩階段提交的思想在MySQL內(nèi)部就是真實(shí)落地了的。注意很多人會(huì)問“既然有redo log了為什么還需要binlog”。本質(zhì)原因是分工不同redo log是InnoDB為了崩潰恢復(fù)和持久性設(shè)計(jì)的它循環(huán)寫、會(huì)覆蓋不能用于全量時(shí)間點(diǎn)恢復(fù)和主從同步binlog是MySQL提供邏輯復(fù)制和審計(jì)能力的二進(jìn)制事件完整、可回溯二者缺一不可。3. MVCC全解析快照讀不鎖行到底靠什么隔離3.1 行記錄里的三個(gè)隱藏字段MVCC全稱Multi-Version Concurrency Control多版本并發(fā)控制。這個(gè)名字聽起來高大上核心就一句話數(shù)據(jù)庫存了這行數(shù)據(jù)的多個(gè)歷史版本事務(wù)讀的時(shí)候通過判斷版本可見性選一個(gè)自己能看的版本這樣就實(shí)現(xiàn)了讀寫互不阻塞。那多版本存在哪除了我們剛說的undo log版本鏈還有一個(gè)關(guān)鍵角色每一行記錄上都有三個(gè)隱藏字段。隱藏字段作用DB_TRX_ID最近一次修改這行記錄的事務(wù)IDDB_ROLL_PTR回滾指針指向上一個(gè)版本的 undo logDB_ROW_ID隱藏主鍵表沒有顯式主鍵時(shí)InnoDB用它生成聚簇索引這三兄弟的分工很明確DB_TRX_ID告訴你這行是誰改的DB_ROLL_PTR告訴你它改之前的舊版在哪。你要看這個(gè)版本對自己可不可見核心就是拿DB_TRX_ID和“當(dāng)前有哪些事務(wù)在跑”這個(gè)信息做比較——這個(gè)信息就是ReadView。有一種叫RR可重復(fù)讀的隔離級(jí)別下事務(wù)第一次執(zhí)行快照讀生成一套R(shí)eadView之后整個(gè)事務(wù)期間都用同一套所以你在同一個(gè)事務(wù)里反復(fù)查看到的數(shù)據(jù)始終是第一次讀時(shí)那個(gè)快照。這就是“可重復(fù)讀”名稱的由來。3.2 ReadView的可見性判斷規(guī)則逐條拆解ReadView不是一張表Transaction隔離級(jí)別的實(shí)現(xiàn)機(jī)制。生成ReadView的那一刻它會(huì)記錄四樣?xùn)|西creator_trx_id創(chuàng)建這個(gè)ReadView的事務(wù)ID。m_ids生成ReadView時(shí)當(dāng)前系統(tǒng)里所有“活躍事務(wù)”的ID列表?；钴S的意思是還沒提交。min_trx_idm_ids里最小的那個(gè)事務(wù)ID。max_trx_id生成ReadView時(shí)系統(tǒng)分配過的下一個(gè)事務(wù)ID。注意這不是當(dāng)前最大的事務(wù)ID而是“預(yù)分配”的表示以后新建的事務(wù)ID都會(huì)大于等于這個(gè)值。有了這四個(gè)值判斷某一行記錄的DB_TRX_ID對當(dāng)前事務(wù)是否可見按下面順序走如果 DB_TRX_ID creator_trx_id說明這行就是當(dāng)前事務(wù)自己改的當(dāng)然可見。如果 DB_TRX_ID min_trx_id說明修改這行的事務(wù)在ReadView生成之前就提交了可見。如果 DB_TRX_ID max_trx_id說明修改這行的事務(wù)是在ReadView生成之后才開啟的不可見。如果 min_trx_id DB_TRX_ID max_trx_id就要查它是否在m_ids里如果在說明這個(gè)事務(wù)還沒提交不可見如果不在說明它已經(jīng)提交了可見。如果按這些規(guī)則判斷當(dāng)前版本不可見就通過DB_ROLL_PTR沿著undo log版本鏈表往前找一直找到可見的版本或者找到頭為止。這個(gè)過程就是MVCC的“版本鏈回溯”。這也是為什么undo log不能隨便刪只要還有活躍的ReadView在用舊版本對應(yīng)的undo log就必須保留下來。3.3 RC和RR的區(qū)別就一個(gè)生成時(shí)機(jī)的事讀已提交RC和可重復(fù)讀RR是MySQL最常用的兩種隔離級(jí)別它們的MVCC判斷邏輯一模一樣唯一區(qū)別就是ReadView的生成時(shí)機(jī)RC每次執(zhí)行快照讀都會(huì)生成一個(gè)新的ReadView所以同一個(gè)事務(wù)里兩次SELECT查詢可能看到別的事務(wù)剛剛提交的新數(shù)據(jù)這就導(dǎo)致不可重復(fù)讀。RR事務(wù)第一次執(zhí)行快照讀時(shí)生成ReadView之后整個(gè)事務(wù)都用這一套不重新生成所以能看到的數(shù)據(jù)始終是第一次讀時(shí)的快照這就是可重復(fù)讀。你看精髓就一句話?？芍貜?fù)讀和讀已提交底層不是兩套機(jī)制就是同一個(gè)機(jī)制換了“什么時(shí)候睜眼”的策略。面試的時(shí)候能把這個(gè)區(qū)別講出來比背一百遍定義都有用。3.4 快照讀和當(dāng)前讀面試時(shí)別搞混講MVCC的可見性時(shí)我一直在強(qiáng)調(diào)“快照讀”因?yàn)镸VCC只管不加鎖的普通SELECT。但還有一類操作叫“當(dāng)前讀”它讀的是數(shù)據(jù)的最新版本并且會(huì)加鎖包括SELECT ... FOR UPDATE加排他鎖SELECT ... LOCK IN SHARE MODE加共享鎖UPDATE、DELETE、INSERT這些操作不能用MVCC的快照必須讀到當(dāng)前最新值否則更新就可能基于舊數(shù)據(jù)覆蓋別人的修改。當(dāng)前讀的并發(fā)控制靠的是鎖這就是下一節(jié)要講的鎖機(jī)制。很多人面試翻車就翻在把“MVCC解決了幻讀”這句話說得太絕對。實(shí)際情況是普通的快照讀靠MVCC解決了幻讀的一部分而當(dāng)前讀靠的是間隙鎖和臨鍵鎖。你要分清楚面試官追問“那如果先用快照讀看到?jīng)]有某行再用當(dāng)前讀去插入會(huì)不會(huì)出問題”你能答出來才算真的懂。4. 鎖機(jī)制當(dāng)前讀并發(fā)控制的地基4.1 S鎖、X鎖、意向鎖先分清粒度InnoDB的鎖可以從多個(gè)維度分類。按“讀寫模式”分有共享鎖S鎖和排他鎖X鎖規(guī)則很簡單S鎖和S鎖可以共存因?yàn)槎贾皇亲x不會(huì)互相影響S鎖和X鎖不能共存X鎖和X鎖也不能共存。一句話總結(jié)——只有讀讀兼容讀寫和寫寫都不兼容。按“鎖粒度”分有行級(jí)鎖和表級(jí)鎖。InnoDB支持行鎖這也是它比MyISAM適合并發(fā)寫的原因之一。但注意InnoDB還有一個(gè)特殊的表級(jí)鎖叫意向鎖當(dāng)一個(gè)事務(wù)要給某一行加S鎖它會(huì)先自動(dòng)在表上加意向共享鎖IS要給某一行加X鎖就先在表上加意向排他鎖IX。意向鎖的意義是當(dāng)一個(gè)事務(wù)想對整張表加鎖比如ALTER TABLE時(shí)可以快速判斷表上有沒有行鎖存在而不需要一行一行去掃描。IS和IX之間是兼容的因?yàn)樗鼈冎皇窃凇氨砑?jí)別打個(gè)標(biāo)記”真正互斥的判斷還是落到行級(jí)別。4.2 記錄鎖、間隙鎖、臨鍵鎖從行鎖到范圍鎖行級(jí)鎖里還有細(xì)分記錄鎖Record Lock鎖的是索引記錄本身。注意InnoDB的行鎖是通過索引實(shí)現(xiàn)的如果你更新數(shù)據(jù)時(shí)沒有走索引那可能會(huì)鎖全表這個(gè)坑后面細(xì)說。間隙鎖Gap Lock鎖的是兩個(gè)索引記錄之間的“間隙”范圍是左開右開比如索引上有1、5、10三條記錄間隙鎖可以鎖1,5這個(gè)區(qū)間在這個(gè)區(qū)間內(nèi)不允許插入新記錄目的是防止“幻讀”——防止別的事務(wù)往縫隙里插入新數(shù)據(jù)。臨鍵鎖Next-Key Lock記錄鎖和間隙鎖的組合范圍是左開右閉。比如鎖的是(1,5]這個(gè)區(qū)間它既鎖住5這條記錄也鎖住1到5之間的間隙。InnoDB在RR隔離級(jí)別下默認(rèn)使用的就是臨鍵鎖。為什么要搞出這么多種鎖因?yàn)楣怄i住已有記錄是不夠的幻讀的本質(zhì)是“事務(wù)A兩次查詢第二次多出來一些之前不存在的記錄”這些新記錄是別的事務(wù)插入進(jìn)來的而插入發(fā)生的位置正是索引記錄之間的“間隙”。所以不鎖住間隙就封不住新插入。4.3 幻讀到底怎么沒的臨鍵鎖實(shí)戰(zhàn)推演我們用一個(gè)具體場景推演一下。假設(shè)一張訂單表orderid是主鍵索引當(dāng)前有id為1、5、10的三條記錄。事務(wù)A執(zhí)行SELECT * FROM order WHERE id 3 FOR UPDATE這是當(dāng)前讀InnoDB會(huì)對滿足條件的范圍加臨鍵鎖實(shí)際鎖住的區(qū)間是(1,5]、(5,10]和(10,正無窮)也就是鎖住了5、10這兩條已有記錄同時(shí)鎖住了它們之間的所有間隙。這時(shí)如果事務(wù)B要插入一條id7的新訂單插入時(shí)它要判斷7落在哪個(gè)間隙里發(fā)現(xiàn)落在(5,10)這個(gè)間隙而這個(gè)間隙被事務(wù)A的間隙鎖鎖住了于是事務(wù)B只能阻塞等待直到事務(wù)A提交或回滾釋放鎖。這樣一來事務(wù)A在事務(wù)期間不管執(zhí)行多少次當(dāng)前讀查到的記錄都不會(huì)多出新的幻讀就被堵死了。如果是普通的快照讀比如不帶 FOR UPDATE 的 SELECT事務(wù)A第一次查詢時(shí)生成了ReadView后續(xù)一直在快照里看本來就不會(huì)看到新插入的數(shù)據(jù)所以也不會(huì)有幻讀問題。但要注意如果事務(wù)A先用快照讀查了一次沒有查到id7然后事務(wù)B插入并提交了id7事務(wù)A此時(shí)執(zhí)行INSERT INTO order ... id7會(huì)因?yàn)橹麈I沖突或者間隙鎖阻塞而報(bào)錯(cuò)——這在RR級(jí)別下確實(shí)可能發(fā)生所以不能把MVCC吹成“完全杜絕一切并發(fā)沖突”只能說它在大部分讀寫場景下保證了隔離性和性能的平衡。注意間隙鎖是有副作用的它會(huì)讓插入操作被莫名阻塞降低并發(fā)度。所以在RC級(jí)別下InnoDB默認(rèn)關(guān)閉了間隙鎖只保留記錄鎖這也是為什么很多高并發(fā)系統(tǒng)會(huì)選擇RC而不是RR——可重復(fù)讀的隔離性帶來了一部分并發(fā)損耗。當(dāng)然RC會(huì)有不可重復(fù)讀問題這就需要業(yè)務(wù)自己權(quán)衡了。5. 面試官愛追的連環(huán)問長事務(wù)、引擎差異和Spring事務(wù)失效5.1 長事務(wù)的危害為什么DBA強(qiáng)調(diào)別開長事務(wù)面試官前面問完原理后面通常喜歡來一句“那長事務(wù)有什么危害”這個(gè)問題看著簡單其實(shí)是在考你的綜合理解。長事務(wù)指的是長時(shí)間不提交的事務(wù)它的危害可以連著原理推導(dǎo)出來一是鎖資源長期占用。RR級(jí)別下當(dāng)前讀加了臨鍵鎖事務(wù)不提交鎖就不釋放其他事務(wù)的DML會(huì)被阻塞接口RT肉眼可見地上升。二是undo log膨脹。MVCC要求舊版本不能被清理因?yàn)榭赡苓€有事務(wù)在按舊ReadView讀數(shù)據(jù)。長事務(wù)一直不提交它生成的ReadView一直存著undo log版本鏈就越攢越長數(shù)據(jù)文件越來越大之后的快照讀要沿著版本鏈回溯很多層才能找到可見版本查詢性能直線下降。三是binlog和redo log相關(guān)的問題。雖然日志本身有存儲(chǔ)清理策略但長事務(wù)會(huì)讓purge線程無法推進(jìn)undo表空間沒法收縮甚至可能因?yàn)閡ndo log膨脹導(dǎo)致磁盤打滿。實(shí)戰(zhàn)建議就是事務(wù)里只放必要的DML和業(yè)務(wù)操作遠(yuǎn)程調(diào)用、消息發(fā)送、文件處理這些耗時(shí)操作千萬別放在事務(wù)里代碼里設(shè)置事務(wù)超時(shí)時(shí)間兜底防止事務(wù)一直掛在那。5.2 為什么MyISAM不支持事務(wù)引擎選型和安裝時(shí)的坑MySQL的存儲(chǔ)引擎是插件式的MyISAM和InnoDB是兩套完全不同的實(shí)現(xiàn)。MyISAM不支持事務(wù)也不支持行級(jí)鎖它當(dāng)年靠的是全表鎖和超快的讀性能在只讀報(bào)表場景還有一定優(yōu)勢但在OLTP高并發(fā)寫場景完全不行。這里要理解一個(gè)關(guān)鍵點(diǎn)事務(wù)的三大底層機(jī)制——redo log、undo log、MVCC、行鎖——都是InnoDB寫在引擎內(nèi)部的。MyISAM引擎沒有實(shí)現(xiàn)這層?xùn)|西所以不管你的事務(wù)隔離級(jí)別設(shè)成什么MyISAM表都不會(huì)真正開啟事務(wù)執(zhí)行事務(wù)操作時(shí)不會(huì)報(bào)錯(cuò)但回滾和原子性保證都不存在。這跟Spring的Transactional注解沒有關(guān)系注解只是告訴Spring去協(xié)調(diào)引擎本身不支持再好的協(xié)調(diào)也沒用。如果你在安裝或使用MySQL時(shí)發(fā)現(xiàn)“事務(wù)不生效”第一件事就是查表的存儲(chǔ)引擎是不是MyISAM。建表時(shí)顯式指定ENGINEInnoDB或者修改default_storage_engineInnoDB這算是DBA和新手最常遇到的坑之一?，F(xiàn)在MySQL 8.0默認(rèn)就是InnoDB但老項(xiàng)目或某些云數(shù)據(jù)庫里MyISAM殘留的情況并不少見。5.3 Spring事務(wù)失效的幾類經(jīng)典場景盤點(diǎn)后端面試到這里Spring事務(wù)失效幾乎是必問的而且特別適合出成“你覺得這個(gè)事務(wù)會(huì)回滾嗎”這種題。我盤一下我自己踩過和見過的高頻踩坑場景第一方法自調(diào)用。在一個(gè)類里方法A調(diào)用同類方法BB上有Transactional但事務(wù)不生效。原因是Spring事務(wù)基于AOP代理實(shí)現(xiàn)只有通過代理對象調(diào)用方法事務(wù)通知才會(huì)介入而自調(diào)用走的是this直接調(diào)用繞過了代理。解決辦法是注入自己的代理或者把B挪到另一個(gè)類。第二非public方法。Spring事務(wù)切面對非public方法不生效這是代理機(jī)制的限制。與其糾結(jié)怎么配置繞過不如直接規(guī)定“事務(wù)方法必須是public”。第三異常被catch吞掉。方法里try-catch捕獲了異常但是沒有拋出Spring感知不到異常自然不會(huì)回滾。解決辦法是不要在事務(wù)方法里吞異常要么重新拋出要么手動(dòng)TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第四拋出的是受檢異常。Spring默認(rèn)只對RuntimeException和Error回滾對受檢異常默認(rèn)不回滾。所以如果要讓受檢異常也回滾要在Transactional(rollbackFor Exception.class)里顯式聲明。第五事務(wù)傳播行為設(shè)置錯(cuò)誤。比如內(nèi)層方法用了REQUIRES_NEW外層事務(wù)回滾時(shí)內(nèi)層已經(jīng)提交了你看到的結(jié)果就是“部分回滾”。第六數(shù)據(jù)庫引擎不支持。這跟前面講的MyISAM問題對應(yīng)上了如果表是MyISAM事務(wù)注解等于白寫。這六類場景每一類都能單獨(dú)出一道面試題而且每一類背后都指向一個(gè)底層原理Spring事務(wù)是通過AOP動(dòng)態(tài)代理協(xié)調(diào)數(shù)據(jù)庫事務(wù)的代理、異常類型、傳播機(jī)制、存儲(chǔ)引擎能力任何一環(huán)不對事務(wù)就失效。6. 常見問題排查與面試速查6.1 面試高頻追問QA速查表整理一份我自己面試時(shí)常用的口答模板用口語化的方式把核心觀點(diǎn)說清楚比背長定義有競爭力得多。面試問題推薦回答思路說一下MySQL事務(wù)的隔離級(jí)別讀未提交有臟讀讀已提交解決臟讀但有不可重復(fù)讀可重復(fù)讀是InnoDB默認(rèn)級(jí)別解決不可重復(fù)讀串行化最嚴(yán)格但性能差。重點(diǎn)說RC和RR的區(qū)別?？芍貜?fù)讀怎么解決幻讀分兩條快照讀靠MVCC的ReadView當(dāng)前讀靠間隙鎖和臨鍵鎖。要主動(dòng)提到“RR下當(dāng)前讀和快照讀可能看到不一致數(shù)據(jù)”這個(gè)坑。MVCC是怎么實(shí)現(xiàn)的隱藏字段DB_TRX_ID、DB_ROLL_PTR加undo log版本鏈外加ReadView的四個(gè)組成值和可見性判斷規(guī)則。redo log和binlog的區(qū)別redo log是InnoDB層物理日志、循環(huán)寫、用于崩潰恢復(fù)binlog是Server層邏輯日志、追加寫、用于主從復(fù)制和時(shí)間點(diǎn)恢復(fù)兩者靠兩階段提交保證一致。什么情況下會(huì)發(fā)生死鎖多個(gè)事務(wù)以不同順序申請同一批資源比如事務(wù)A先鎖id1再鎖id2事務(wù)B先鎖id2再鎖id1互相等著對方釋放。InnoDB會(huì)檢測死鎖并回滾代價(jià)較小的事務(wù)但最好還是通過固定加鎖順序避免死鎖。事務(wù)提交時(shí)數(shù)據(jù)什么時(shí)候落盤提交時(shí)只保證redo log落盤數(shù)據(jù)頁靠checkpoint機(jī)制在后臺(tái)異步刷盤這就是WAL。一條UPDATE的執(zhí)行鏈路先寫undo log在Buffer Pool中改數(shù)據(jù)頁記錄redo logprepare寫binlogredo log標(biāo)記commit最終臟頁異步刷盤。這套QA不是讓你背答案而是幫你建立“先結(jié)論后原理”的答題結(jié)構(gòu)。面試官聽的是你推導(dǎo)過程是否清晰不是聽你背得多流利。6.2 我實(shí)戰(zhàn)中踩過的幾個(gè)事務(wù)相關(guān)的坑最后分享幾個(gè)我在真實(shí)項(xiàng)目里排查過的坑每一個(gè)都花了不小的代價(jià)才定位到根因?qū)懗鰜硐Ｍ蠹疑僮邚澛?。第一個(gè)坑是“事務(wù)里做了遠(yuǎn)程調(diào)用”。當(dāng)時(shí)一個(gè)下單接口開啟事務(wù)后調(diào)用了庫存服務(wù)的HTTP接口結(jié)果庫存服務(wù)響應(yīng)超時(shí)HTTP調(diào)用的等待時(shí)間把事務(wù)拉得特別長數(shù)據(jù)庫連接池被占滿整個(gè)服務(wù)雪崩。后來把遠(yuǎn)程調(diào)用挪到事務(wù)外面事務(wù)里只留著更新本庫訂單表的操作問題立刻緩解。第二個(gè)坑是“大事務(wù)批量更新導(dǎo)致的死鎖”。系統(tǒng)里有個(gè)月度結(jié)算任務(wù)開啟一個(gè)大事務(wù)循環(huán)更新幾千條數(shù)據(jù)。因?yàn)檠h(huán)里更新是無序的兩個(gè)批次之間加鎖順序不一致偶爾就觸發(fā)死鎖。后來把所有更新的主鍵排序統(tǒng)一按順序更新死鎖基本消失。第三個(gè)坑是“RC下間隙鎖關(guān)閉帶來的并發(fā)問題”。一個(gè)高并發(fā)扣減庫存的系統(tǒng)把數(shù)據(jù)庫隔離級(jí)別從RR調(diào)成了RC來提升并發(fā)性能結(jié)果扣減后超賣——因?yàn)镽C下沒有間隙鎖兩個(gè)事務(wù)同時(shí)讀到庫存為1都執(zhí)行了扣減。最后在UPDATE語句里加了UPDATE ... WHERE stock 0的原子條件靠數(shù)據(jù)庫層面的條件判斷來兜底才徹底解決超賣問題。這三個(gè)坑的共同點(diǎn)是事務(wù)原理不是書上的理論只要線上出問題最終都會(huì)回到鎖、日志、隔離級(jí)別這些底層概念上。你理解得越透排查越快。我個(gè)人更推薦在學(xué)習(xí)事務(wù)原理時(shí)找一臺(tái)本地MySQL實(shí)例開兩個(gè)終端用BEGIN開事務(wù)手動(dòng)在不同隔離級(jí)別下做實(shí)驗(yàn)查information_schema.innodb_trx看活躍事務(wù)用SHOW ENGINE INNODB STATUS看鎖等待和死鎖信息。這種“動(dòng)手推演”的方式比背任何八股文都管用。面試遇到事務(wù)題時(shí)能舉一個(gè)自己實(shí)驗(yàn)過的例子比夸夸其談強(qiáng)一百倍。 MySQL事務(wù)底層原理：redo log、undo log、MVCC與鎖機(jī)制全解析
前幾天我一個(gè)朋友去面某廠的Java后端崗被問到“MySQL事務(wù)的底層原理是什么”他說自己當(dāng)時(shí)腦子里蹦出來的只有ACID四個(gè)字母其他的什么redo log、undo log、MVCC、間隙鎖全卡殼了。這個(gè)問題我去面別人的時(shí)候也喜歡問倒不是為了刁難人而是它真的很能區(qū)分一個(gè)人是背過八股還是真把數(shù)據(jù)庫搞通過。MySQL事務(wù)這塊的知識(shí)點(diǎn)是隔離級(jí)別、日志機(jī)制、索引結(jié)構(gòu)、并發(fā)控制、甚至Spring事務(wù)管理的交匯點(diǎn)你把這一條線理清了數(shù)據(jù)庫這塊的面試基本就穩(wěn)了一大半。這篇文章我按我自己做面試復(fù)盤的習(xí)慣來寫把MySQL事務(wù)底層原理拆成六塊先講事務(wù)解決什么問題再講redo log、undo log、binlog三大日志然后是MVCC和ReadView接著是鎖和幻讀的解法最后補(bǔ)上長事務(wù)、Spring事務(wù)失效這些高頻追問以及一份可以直接背的面試速查。適合準(zhǔn)備秋招春招的Java后端、需要梳理知識(shí)體系的MySQL使用者還有那些“用事務(wù)用了好幾年但說不清原理”的工程師。1. 先弄明白事務(wù)到底在解決什么問題1.1 從一個(gè)經(jīng)典的扣款場景說起講事務(wù)原理之前先想一個(gè)每個(gè)后端都寫過的代碼轉(zhuǎn)賬。A賬戶扣100塊B賬戶加100塊。如果扣完A的錢之后系統(tǒng)突然斷電了B的錢沒加這錢就憑空消失了。業(yè)務(wù)上絕對不允許這種狀態(tài)出現(xiàn)所以我們要把“扣A”和“加B”綁成一個(gè)整體要么都成功要么都失敗——這個(gè)“整體”就是事務(wù)。但事務(wù)不是只解決“全成功或全失敗”這一個(gè)問題。你在高并發(fā)場景下還會(huì)遇到別的麻煩兩個(gè)用戶同時(shí)讀同一個(gè)數(shù)據(jù)一個(gè)改了另一個(gè)還在用舊值一個(gè)事務(wù)在統(tǒng)計(jì)總額另一個(gè)事務(wù)在瘋狂插入新訂單統(tǒng)計(jì)結(jié)果一會(huì)兒多一條一會(huì)兒少一條兩個(gè)人同時(shí)改同一行數(shù)據(jù)最后誰覆蓋誰……這些問題事務(wù)都要管。所以數(shù)據(jù)庫的事務(wù)機(jī)制本質(zhì)上是應(yīng)對四類問題的工具原子性管“要么全做要么全不做”一致性管“數(shù)據(jù)永遠(yuǎn)滿足業(yè)務(wù)規(guī)則”隔離性管“并發(fā)事務(wù)之間互不干擾”持久性管“數(shù)據(jù)提交了就不會(huì)丟”。這四件事看著抽象底層都有實(shí)打?qū)嵉臋C(jī)制在支撐后面幾節(jié)我會(huì)一個(gè)個(gè)對應(yīng)著講。1.2 ACID四兄弟各自的底層靠山很多人背ACID就是背字母面試被追問一句“原子性靠什么實(shí)現(xiàn)”就啞火了。這里給你一張對照表把四兄弟和底層機(jī)制對應(yīng)起來ACID特性解決什么問題底層核心機(jī)制原子性 Atomicity事務(wù)內(nèi)操作要么全成功要么全回滾undo log回滾日志一致性 Consistency數(shù)據(jù)在事務(wù)前后滿足約束和業(yè)務(wù)規(guī)則應(yīng)用代碼 數(shù)據(jù)庫約束 其他三個(gè)特性共同保證隔離性 Isolation并發(fā)事務(wù)不互相干擾鎖機(jī)制 MVCC多版本并發(fā)控制持久性 Durability事務(wù)提交后數(shù)據(jù)不丟失redo log重做日志 binlog注意一致性跟前三個(gè)不一樣它不是一個(gè)獨(dú)立的機(jī)制更像是“目的”。原子性、隔離性、持久性都做到了一致性這個(gè)結(jié)果自然就有了。比如轉(zhuǎn)賬場景只要原子性保證了扣款和加款同時(shí)成功或同時(shí)失敗賬就是平的一致性就滿足了。但有些一致性靠數(shù)據(jù)庫管不了比如“庫存不能為負(fù)數(shù)”你得在業(yè)務(wù)代碼里判斷或者建一個(gè)CHECK約束數(shù)據(jù)庫沒有義務(wù)替你想業(yè)務(wù)規(guī)則。面試官如果問“ACID分別靠什么實(shí)現(xiàn)”你就說原子性靠undo log回滾持久性靠redo log和binlog隔離性靠鎖和MVCC一致性是前三者共同作用的結(jié)果。這個(gè)答案一句話就把后面所有細(xì)節(jié)串起來了。2. 三大日志redo log、undo log、binlog底層持久化的命根子2.1 redo log為什么必須存在隨機(jī)寫和順序?qū)懙牟顒e先問一個(gè)問題InnoDB的數(shù)據(jù)是存在哪里的存在磁盤上的B樹索引文件里這個(gè)沒問題。但你要知道你執(zhí)行一條UPDATE語句InnoDB不是馬上去改磁盤上那個(gè)B樹頁里的數(shù)據(jù)因?yàn)榇疟P隨機(jī)讀寫太慢了。它是先把對應(yīng)的數(shù)據(jù)頁加載到內(nèi)存的Buffer Pool里在內(nèi)存里改掉然后事務(wù)提交的時(shí)候就把這個(gè)修改記錄到redo log里redo log是順序追加寫的比隨機(jī)寫快幾個(gè)數(shù)量級(jí)。之后系統(tǒng)會(huì)在某個(gè)合適的時(shí)間再把內(nèi)存里的臟頁刷回磁盤。這就是WAL機(jī)制Write-Ahead Logging先寫日志再寫數(shù)據(jù)。為什么要這么設(shè)計(jì)生活化類比一下你開了個(gè)飯店每天的流水很大每來一桌客人都把賬本翻出來改會(huì)很慢你也怕客人走了忘記。所以你先在一個(gè)小本子上按順序記“今天第幾桌點(diǎn)了什么菜花了多少錢”晚上打烊了再慢慢把它謄寫到正式賬本上。萬一中途停電了你手上的小本子還在賬就不會(huì)丟。redo log有兩個(gè)關(guān)鍵特性它是物理日志記錄的是“某個(gè)頁的某個(gè)偏移量改成了什么值”而不是“執(zhí)行了什么SQL”所以恢復(fù)速度很快它的文件是固定大小、循環(huán)寫的寫滿了會(huì)觸發(fā)checkpoint把臟頁刷盤、推進(jìn)LSN日志序列號(hào)然后把舊日志覆蓋掉。redo log的“重做”能力就是崩潰恢復(fù)時(shí)把那些已經(jīng)提交但還沒來得及刷盤的數(shù)據(jù)頁重新應(yīng)用一遍日志保證不會(huì)丟已提交的事務(wù)。這也正是持久性的核心。2.2 undo log回滾和MVCC版本鏈的起點(diǎn)redo log負(fù)責(zé)“重做”undo log正好相反負(fù)責(zé)“撤銷”。事務(wù)執(zhí)行過程中每改一行數(shù)據(jù)InnoDB都會(huì)記一條undo log里面保存的是這行數(shù)據(jù)修改前的樣子。事務(wù)回滾的時(shí)候就拿著undo log把數(shù)據(jù)改回去。舉個(gè)簡潔的例子事務(wù)T1執(zhí)行UPDATE user SET age 30 WHERE id 1原來age是20。InnoDB會(huì)先寫一條undo logid1這行原來的age20然后才把a(bǔ)ge改成30。如果T1要回滾就根據(jù)這條undo log把a(bǔ)ge改回20。但undo log的作用不止回滾它還是MVCC的地基。每一行數(shù)據(jù)上都會(huì)有一個(gè)隱藏的DB_ROLL_PTR字段指向它上一個(gè)版本的undo log這樣多個(gè)版本的數(shù)據(jù)就串成了一條“版本鏈”。后面講MVCC時(shí)你會(huì)看到這條版本鏈就是事務(wù)判斷“哪個(gè)版本對我來說可見”的關(guān)鍵。另外有個(gè)很多人忽略的細(xì)節(jié)undo log也是要持久化的它也要寫redo log因?yàn)槿绻罎⒘藘?nèi)存里的undo信息丟了沒有redo的話連回滾都做不了。這個(gè)點(diǎn)面試不常見但提出來會(huì)顯得你確實(shí)讀過源碼層面的東西。2.3 binlog 兩階段提交主從復(fù)制和數(shù)據(jù)一致性的保障redo log是InnoDB存儲(chǔ)引擎層的日志binlog則是MySQL Server層的日志。redo log記錄頁級(jí)物理修改binlog記錄的是邏輯SQL或者說“做了什么變更”并且binlog是追加寫的不會(huì)覆蓋所以它才是主從復(fù)制和數(shù)據(jù)恢復(fù)的主角從庫拿到binlog在本地重放一遍就變成了主庫的樣子。但這就有個(gè)嚴(yán)重問題redo log是引擎層的binlog是Server層的兩層日志各自寫各自的萬一寫完還沒寫完就崩了數(shù)據(jù)就不一致了。比如主庫redo log里已經(jīng)標(biāo)記事務(wù)提交了但binlog還沒來得及寫這時(shí)候從庫同步不到這條變更主從就亂了。解決辦法是兩階段提交事務(wù)提交時(shí)先寫redo log并標(biāo)記為prepare狀態(tài)然后寫binlog最后再把redo log標(biāo)記為commit狀態(tài)。崩潰恢復(fù)時(shí)MySQL會(huì)檢查所有狀態(tài)為prepare的redo log看對應(yīng)的binlog是否完整如果binlog完整就判定事務(wù)可以提交補(bǔ)一條commit如果binlog不完整就回滾這個(gè)事務(wù)。因?yàn)閎inlog寫完整的那一刻主從才能拿到一致的數(shù)據(jù)。這個(gè)設(shè)計(jì)保證了引擎日志和Server日志的最終一致也是面試?yán)铩癲istributed transaction的Mini版”——兩階段提交的思想在MySQL內(nèi)部就是真實(shí)落地了的。注意很多人會(huì)問“既然有redo log了為什么還需要binlog”。本質(zhì)原因是分工不同redo log是InnoDB為了崩潰恢復(fù)和持久性設(shè)計(jì)的它循環(huán)寫、會(huì)覆蓋不能用于全量時(shí)間點(diǎn)恢復(fù)和主從同步binlog是MySQL提供邏輯復(fù)制和審計(jì)能力的二進(jìn)制事件完整、可回溯二者缺一不可。3. MVCC全解析快照讀不鎖行到底靠什么隔離3.1 行記錄里的三個(gè)隱藏字段MVCC全稱Multi-Version Concurrency Control多版本并發(fā)控制。這個(gè)名字聽起來高大上核心就一句話數(shù)據(jù)庫存了這行數(shù)據(jù)的多個(gè)歷史版本事務(wù)讀的時(shí)候通過判斷版本可見性選一個(gè)自己能看的版本這樣就實(shí)現(xiàn)了讀寫互不阻塞。那多版本存在哪除了我們剛說的undo log版本鏈還有一個(gè)關(guān)鍵角色每一行記錄上都有三個(gè)隱藏字段。隱藏字段作用DB_TRX_ID最近一次修改這行記錄的事務(wù)IDDB_ROLL_PTR回滾指針指向上一個(gè)版本的 undo logDB_ROW_ID隱藏主鍵表沒有顯式主鍵時(shí)InnoDB用它生成聚簇索引這三兄弟的分工很明確DB_TRX_ID告訴你這行是誰改的DB_ROLL_PTR告訴你它改之前的舊版在哪。你要看這個(gè)版本對自己可不可見核心就是拿DB_TRX_ID和“當(dāng)前有哪些事務(wù)在跑”這個(gè)信息做比較——這個(gè)信息就是ReadView。有一種叫RR可重復(fù)讀的隔離級(jí)別下事務(wù)第一次執(zhí)行快照讀生成一套R(shí)eadView之后整個(gè)事務(wù)期間都用同一套所以你在同一個(gè)事務(wù)里反復(fù)查看到的數(shù)據(jù)始終是第一次讀時(shí)那個(gè)快照。這就是“可重復(fù)讀”名稱的由來。3.2 ReadView的可見性判斷規(guī)則逐條拆解ReadView不是一張表Transaction隔離級(jí)別的實(shí)現(xiàn)機(jī)制。生成ReadView的那一刻它會(huì)記錄四樣?xùn)|西creator_trx_id創(chuàng)建這個(gè)ReadView的事務(wù)ID。m_ids生成ReadView時(shí)當(dāng)前系統(tǒng)里所有“活躍事務(wù)”的ID列表?；钴S的意思是還沒提交。min_trx_idm_ids里最小的那個(gè)事務(wù)ID。max_trx_id生成ReadView時(shí)系統(tǒng)分配過的下一個(gè)事務(wù)ID。注意這不是當(dāng)前最大的事務(wù)ID而是“預(yù)分配”的表示以后新建的事務(wù)ID都會(huì)大于等于這個(gè)值。有了這四個(gè)值判斷某一行記錄的DB_TRX_ID對當(dāng)前事務(wù)是否可見按下面順序走如果 DB_TRX_ID creator_trx_id說明這行就是當(dāng)前事務(wù)自己改的當(dāng)然可見。如果 DB_TRX_ID min_trx_id說明修改這行的事務(wù)在ReadView生成之前就提交了可見。如果 DB_TRX_ID max_trx_id說明修改這行的事務(wù)是在ReadView生成之后才開啟的不可見。如果 min_trx_id DB_TRX_ID max_trx_id就要查它是否在m_ids里如果在說明這個(gè)事務(wù)還沒提交不可見如果不在說明它已經(jīng)提交了可見。如果按這些規(guī)則判斷當(dāng)前版本不可見就通過DB_ROLL_PTR沿著undo log版本鏈表往前找一直找到可見的版本或者找到頭為止。這個(gè)過程就是MVCC的“版本鏈回溯”。這也是為什么undo log不能隨便刪只要還有活躍的ReadView在用舊版本對應(yīng)的undo log就必須保留下來。3.3 RC和RR的區(qū)別就一個(gè)生成時(shí)機(jī)的事讀已提交RC和可重復(fù)讀RR是MySQL最常用的兩種隔離級(jí)別它們的MVCC判斷邏輯一模一樣唯一區(qū)別就是ReadView的生成時(shí)機(jī)RC每次執(zhí)行快照讀都會(huì)生成一個(gè)新的ReadView所以同一個(gè)事務(wù)里兩次SELECT查詢可能看到別的事務(wù)剛剛提交的新數(shù)據(jù)這就導(dǎo)致不可重復(fù)讀。RR事務(wù)第一次執(zhí)行快照讀時(shí)生成ReadView之后整個(gè)事務(wù)都用這一套不重新生成所以能看到的數(shù)據(jù)始終是第一次讀時(shí)的快照這就是可重復(fù)讀。你看精髓就一句話?？芍貜?fù)讀和讀已提交底層不是兩套機(jī)制就是同一個(gè)機(jī)制換了“什么時(shí)候睜眼”的策略。面試的時(shí)候能把這個(gè)區(qū)別講出來比背一百遍定義都有用。3.4 快照讀和當(dāng)前讀面試時(shí)別搞混講MVCC的可見性時(shí)我一直在強(qiáng)調(diào)“快照讀”因?yàn)镸VCC只管不加鎖的普通SELECT。但還有一類操作叫“當(dāng)前讀”它讀的是數(shù)據(jù)的最新版本并且會(huì)加鎖包括SELECT ... FOR UPDATE加排他鎖SELECT ... LOCK IN SHARE MODE加共享鎖UPDATE、DELETE、INSERT這些操作不能用MVCC的快照必須讀到當(dāng)前最新值否則更新就可能基于舊數(shù)據(jù)覆蓋別人的修改。當(dāng)前讀的并發(fā)控制靠的是鎖這就是下一節(jié)要講的鎖機(jī)制。很多人面試翻車就翻在把“MVCC解決了幻讀”這句話說得太絕對。實(shí)際情況是普通的快照讀靠MVCC解決了幻讀的一部分而當(dāng)前讀靠的是間隙鎖和臨鍵鎖。你要分清楚面試官追問“那如果先用快照讀看到?jīng)]有某行再用當(dāng)前讀去插入會(huì)不會(huì)出問題”你能答出來才算真的懂。4. 鎖機(jī)制當(dāng)前讀并發(fā)控制的地基4.1 S鎖、X鎖、意向鎖先分清粒度InnoDB的鎖可以從多個(gè)維度分類。按“讀寫模式”分有共享鎖S鎖和排他鎖X鎖規(guī)則很簡單S鎖和S鎖可以共存因?yàn)槎贾皇亲x不會(huì)互相影響S鎖和X鎖不能共存X鎖和X鎖也不能共存。一句話總結(jié)——只有讀讀兼容讀寫和寫寫都不兼容。按“鎖粒度”分有行級(jí)鎖和表級(jí)鎖。InnoDB支持行鎖這也是它比MyISAM適合并發(fā)寫的原因之一。但注意InnoDB還有一個(gè)特殊的表級(jí)鎖叫意向鎖當(dāng)一個(gè)事務(wù)要給某一行加S鎖它會(huì)先自動(dòng)在表上加意向共享鎖IS要給某一行加X鎖就先在表上加意向排他鎖IX。意向鎖的意義是當(dāng)一個(gè)事務(wù)想對整張表加鎖比如ALTER TABLE時(shí)可以快速判斷表上有沒有行鎖存在而不需要一行一行去掃描。IS和IX之間是兼容的因?yàn)樗鼈冎皇窃凇氨砑?jí)別打個(gè)標(biāo)記”真正互斥的判斷還是落到行級(jí)別。4.2 記錄鎖、間隙鎖、臨鍵鎖從行鎖到范圍鎖行級(jí)鎖里還有細(xì)分記錄鎖Record Lock鎖的是索引記錄本身。注意InnoDB的行鎖是通過索引實(shí)現(xiàn)的如果你更新數(shù)據(jù)時(shí)沒有走索引那可能會(huì)鎖全表這個(gè)坑后面細(xì)說。間隙鎖Gap Lock鎖的是兩個(gè)索引記錄之間的“間隙”范圍是左開右開比如索引上有1、5、10三條記錄間隙鎖可以鎖1,5這個(gè)區(qū)間在這個(gè)區(qū)間內(nèi)不允許插入新記錄目的是防止“幻讀”——防止別的事務(wù)往縫隙里插入新數(shù)據(jù)。臨鍵鎖Next-Key Lock記錄鎖和間隙鎖的組合范圍是左開右閉。比如鎖的是(1,5]這個(gè)區(qū)間它既鎖住5這條記錄也鎖住1到5之間的間隙。InnoDB在RR隔離級(jí)別下默認(rèn)使用的就是臨鍵鎖。為什么要搞出這么多種鎖因?yàn)楣怄i住已有記錄是不夠的幻讀的本質(zhì)是“事務(wù)A兩次查詢第二次多出來一些之前不存在的記錄”這些新記錄是別的事務(wù)插入進(jìn)來的而插入發(fā)生的位置正是索引記錄之間的“間隙”。所以不鎖住間隙就封不住新插入。4.3 幻讀到底怎么沒的臨鍵鎖實(shí)戰(zhàn)推演我們用一個(gè)具體場景推演一下。假設(shè)一張訂單表orderid是主鍵索引當(dāng)前有id為1、5、10的三條記錄。事務(wù)A執(zhí)行SELECT * FROM order WHERE id 3 FOR UPDATE這是當(dāng)前讀InnoDB會(huì)對滿足條件的范圍加臨鍵鎖實(shí)際鎖住的區(qū)間是(1,5]、(5,10]和(10,正無窮)也就是鎖住了5、10這兩條已有記錄同時(shí)鎖住了它們之間的所有間隙。這時(shí)如果事務(wù)B要插入一條id7的新訂單插入時(shí)它要判斷7落在哪個(gè)間隙里發(fā)現(xiàn)落在(5,10)這個(gè)間隙而這個(gè)間隙被事務(wù)A的間隙鎖鎖住了于是事務(wù)B只能阻塞等待直到事務(wù)A提交或回滾釋放鎖。這樣一來事務(wù)A在事務(wù)期間不管執(zhí)行多少次當(dāng)前讀查到的記錄都不會(huì)多出新的幻讀就被堵死了。如果是普通的快照讀比如不帶 FOR UPDATE 的 SELECT事務(wù)A第一次查詢時(shí)生成了ReadView后續(xù)一直在快照里看本來就不會(huì)看到新插入的數(shù)據(jù)所以也不會(huì)有幻讀問題。但要注意如果事務(wù)A先用快照讀查了一次沒有查到id7然后事務(wù)B插入并提交了id7事務(wù)A此時(shí)執(zhí)行INSERT INTO order ... id7會(huì)因?yàn)橹麈I沖突或者間隙鎖阻塞而報(bào)錯(cuò)——這在RR級(jí)別下確實(shí)可能發(fā)生所以不能把MVCC吹成“完全杜絕一切并發(fā)沖突”只能說它在大部分讀寫場景下保證了隔離性和性能的平衡。注意間隙鎖是有副作用的它會(huì)讓插入操作被莫名阻塞降低并發(fā)度。所以在RC級(jí)別下InnoDB默認(rèn)關(guān)閉了間隙鎖只保留記錄鎖這也是為什么很多高并發(fā)系統(tǒng)會(huì)選擇RC而不是RR——可重復(fù)讀的隔離性帶來了一部分并發(fā)損耗。當(dāng)然RC會(huì)有不可重復(fù)讀問題這就需要業(yè)務(wù)自己權(quán)衡了。5. 面試官愛追的連環(huán)問長事務(wù)、引擎差異和Spring事務(wù)失效5.1 長事務(wù)的危害為什么DBA強(qiáng)調(diào)別開長事務(wù)面試官前面問完原理后面通常喜歡來一句“那長事務(wù)有什么危害”這個(gè)問題看著簡單其實(shí)是在考你的綜合理解。長事務(wù)指的是長時(shí)間不提交的事務(wù)它的危害可以連著原理推導(dǎo)出來一是鎖資源長期占用。RR級(jí)別下當(dāng)前讀加了臨鍵鎖事務(wù)不提交鎖就不釋放其他事務(wù)的DML會(huì)被阻塞接口RT肉眼可見地上升。二是undo log膨脹。MVCC要求舊版本不能被清理因?yàn)榭赡苓€有事務(wù)在按舊ReadView讀數(shù)據(jù)。長事務(wù)一直不提交它生成的ReadView一直存著undo log版本鏈就越攢越長數(shù)據(jù)文件越來越大之后的快照讀要沿著版本鏈回溯很多層才能找到可見版本查詢性能直線下降。三是binlog和redo log相關(guān)的問題。雖然日志本身有存儲(chǔ)清理策略但長事務(wù)會(huì)讓purge線程無法推進(jìn)undo表空間沒法收縮甚至可能因?yàn)閡ndo log膨脹導(dǎo)致磁盤打滿。實(shí)戰(zhàn)建議就是事務(wù)里只放必要的DML和業(yè)務(wù)操作遠(yuǎn)程調(diào)用、消息發(fā)送、文件處理這些耗時(shí)操作千萬別放在事務(wù)里代碼里設(shè)置事務(wù)超時(shí)時(shí)間兜底防止事務(wù)一直掛在那。5.2 為什么MyISAM不支持事務(wù)引擎選型和安裝時(shí)的坑MySQL的存儲(chǔ)引擎是插件式的MyISAM和InnoDB是兩套完全不同的實(shí)現(xiàn)。MyISAM不支持事務(wù)也不支持行級(jí)鎖它當(dāng)年靠的是全表鎖和超快的讀性能在只讀報(bào)表場景還有一定優(yōu)勢但在OLTP高并發(fā)寫場景完全不行。這里要理解一個(gè)關(guān)鍵點(diǎn)事務(wù)的三大底層機(jī)制——redo log、undo log、MVCC、行鎖——都是InnoDB寫在引擎內(nèi)部的。MyISAM引擎沒有實(shí)現(xiàn)這層?xùn)|西所以不管你的事務(wù)隔離級(jí)別設(shè)成什么MyISAM表都不會(huì)真正開啟事務(wù)執(zhí)行事務(wù)操作時(shí)不會(huì)報(bào)錯(cuò)但回滾和原子性保證都不存在。這跟Spring的Transactional注解沒有關(guān)系注解只是告訴Spring去協(xié)調(diào)引擎本身不支持再好的協(xié)調(diào)也沒用。如果你在安裝或使用MySQL時(shí)發(fā)現(xiàn)“事務(wù)不生效”第一件事就是查表的存儲(chǔ)引擎是不是MyISAM。建表時(shí)顯式指定ENGINEInnoDB或者修改default_storage_engineInnoDB這算是DBA和新手最常遇到的坑之一?，F(xiàn)在MySQL 8.0默認(rèn)就是InnoDB但老項(xiàng)目或某些云數(shù)據(jù)庫里MyISAM殘留的情況并不少見。5.3 Spring事務(wù)失效的幾類經(jīng)典場景盤點(diǎn)后端面試到這里Spring事務(wù)失效幾乎是必問的而且特別適合出成“你覺得這個(gè)事務(wù)會(huì)回滾嗎”這種題。我盤一下我自己踩過和見過的高頻踩坑場景第一方法自調(diào)用。在一個(gè)類里方法A調(diào)用同類方法BB上有Transactional但事務(wù)不生效。原因是Spring事務(wù)基于AOP代理實(shí)現(xiàn)只有通過代理對象調(diào)用方法事務(wù)通知才會(huì)介入而自調(diào)用走的是this直接調(diào)用繞過了代理。解決辦法是注入自己的代理或者把B挪到另一個(gè)類。第二非public方法。Spring事務(wù)切面對非public方法不生效這是代理機(jī)制的限制。與其糾結(jié)怎么配置繞過不如直接規(guī)定“事務(wù)方法必須是public”。第三異常被catch吞掉。方法里try-catch捕獲了異常但是沒有拋出Spring感知不到異常自然不會(huì)回滾。解決辦法是不要在事務(wù)方法里吞異常要么重新拋出要么手動(dòng)TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第四拋出的是受檢異常。Spring默認(rèn)只對RuntimeException和Error回滾對受檢異常默認(rèn)不回滾。所以如果要讓受檢異常也回滾要在Transactional(rollbackFor Exception.class)里顯式聲明。第五事務(wù)傳播行為設(shè)置錯(cuò)誤。比如內(nèi)層方法用了REQUIRES_NEW外層事務(wù)回滾時(shí)內(nèi)層已經(jīng)提交了你看到的結(jié)果就是“部分回滾”。第六數(shù)據(jù)庫引擎不支持。這跟前面講的MyISAM問題對應(yīng)上了如果表是MyISAM事務(wù)注解等于白寫。這六類場景每一類都能單獨(dú)出一道面試題而且每一類背后都指向一個(gè)底層原理Spring事務(wù)是通過AOP動(dòng)態(tài)代理協(xié)調(diào)數(shù)據(jù)庫事務(wù)的代理、異常類型、傳播機(jī)制、存儲(chǔ)引擎能力任何一環(huán)不對事務(wù)就失效。6. 常見問題排查與面試速查6.1 面試高頻追問QA速查表整理一份我自己面試時(shí)常用的口答模板用口語化的方式把核心觀點(diǎn)說清楚比背長定義有競爭力得多。面試問題推薦回答思路說一下MySQL事務(wù)的隔離級(jí)別讀未提交有臟讀讀已提交解決臟讀但有不可重復(fù)讀可重復(fù)讀是InnoDB默認(rèn)級(jí)別解決不可重復(fù)讀串行化最嚴(yán)格但性能差。重點(diǎn)說RC和RR的區(qū)別?？芍貜?fù)讀怎么解決幻讀分兩條快照讀靠MVCC的ReadView當(dāng)前讀靠間隙鎖和臨鍵鎖。要主動(dòng)提到“RR下當(dāng)前讀和快照讀可能看到不一致數(shù)據(jù)”這個(gè)坑。MVCC是怎么實(shí)現(xiàn)的隱藏字段DB_TRX_ID、DB_ROLL_PTR加undo log版本鏈外加ReadView的四個(gè)組成值和可見性判斷規(guī)則。redo log和binlog的區(qū)別redo log是InnoDB層物理日志、循環(huán)寫、用于崩潰恢復(fù)binlog是Server層邏輯日志、追加寫、用于主從復(fù)制和時(shí)間點(diǎn)恢復(fù)兩者靠兩階段提交保證一致。什么情況下會(huì)發(fā)生死鎖多個(gè)事務(wù)以不同順序申請同一批資源比如事務(wù)A先鎖id1再鎖id2事務(wù)B先鎖id2再鎖id1互相等著對方釋放。InnoDB會(huì)檢測死鎖并回滾代價(jià)較小的事務(wù)但最好還是通過固定加鎖順序避免死鎖。事務(wù)提交時(shí)數(shù)據(jù)什么時(shí)候落盤提交時(shí)只保證redo log落盤數(shù)據(jù)頁靠checkpoint機(jī)制在后臺(tái)異步刷盤這就是WAL。一條UPDATE的執(zhí)行鏈路先寫undo log在Buffer Pool中改數(shù)據(jù)頁記錄redo logprepare寫binlogredo log標(biāo)記commit最終臟頁異步刷盤。這套QA不是讓你背答案而是幫你建立“先結(jié)論后原理”的答題結(jié)構(gòu)。面試官聽的是你推導(dǎo)過程是否清晰不是聽你背得多流利。6.2 我實(shí)戰(zhàn)中踩過的幾個(gè)事務(wù)相關(guān)的坑最后分享幾個(gè)我在真實(shí)項(xiàng)目里排查過的坑每一個(gè)都花了不小的代價(jià)才定位到根因?qū)懗鰜硐Ｍ蠹疑僮邚澛?。第一個(gè)坑是“事務(wù)里做了遠(yuǎn)程調(diào)用”。當(dāng)時(shí)一個(gè)下單接口開啟事務(wù)后調(diào)用了庫存服務(wù)的HTTP接口結(jié)果庫存服務(wù)響應(yīng)超時(shí)HTTP調(diào)用的等待時(shí)間把事務(wù)拉得特別長數(shù)據(jù)庫連接池被占滿整個(gè)服務(wù)雪崩。后來把遠(yuǎn)程調(diào)用挪到事務(wù)外面事務(wù)里只留著更新本庫訂單表的操作問題立刻緩解。第二個(gè)坑是“大事務(wù)批量更新導(dǎo)致的死鎖”。系統(tǒng)里有個(gè)月度結(jié)算任務(wù)開啟一個(gè)大事務(wù)循環(huán)更新幾千條數(shù)據(jù)。因?yàn)檠h(huán)里更新是無序的兩個(gè)批次之間加鎖順序不一致偶爾就觸發(fā)死鎖。后來把所有更新的主鍵排序統(tǒng)一按順序更新死鎖基本消失。第三個(gè)坑是“RC下間隙鎖關(guān)閉帶來的并發(fā)問題”。一個(gè)高并發(fā)扣減庫存的系統(tǒng)把數(shù)據(jù)庫隔離級(jí)別從RR調(diào)成了RC來提升并發(fā)性能結(jié)果扣減后超賣——因?yàn)镽C下沒有間隙鎖兩個(gè)事務(wù)同時(shí)讀到庫存為1都執(zhí)行了扣減。最后在UPDATE語句里加了UPDATE ... WHERE stock 0的原子條件靠數(shù)據(jù)庫層面的條件判斷來兜底才徹底解決超賣問題。這三個(gè)坑的共同點(diǎn)是事務(wù)原理不是書上的理論只要線上出問題最終都會(huì)回到鎖、日志、隔離級(jí)別這些底層概念上。你理解得越透排查越快。我個(gè)人更推薦在學(xué)習(xí)事務(wù)原理時(shí)找一臺(tái)本地MySQL實(shí)例開兩個(gè)終端用BEGIN開事務(wù)手動(dòng)在不同隔離級(jí)別下做實(shí)驗(yàn)查information_schema.innodb_trx看活躍事務(wù)用SHOW ENGINE INNODB STATUS看鎖等待和死鎖信息。這種“動(dòng)手推演”的方式比背任何八股文都管用。面試遇到事務(wù)題時(shí)能舉一個(gè)自己實(shí)驗(yàn)過的例子比夸夸其談強(qiáng)一百倍。