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