：從ACID到隔離級別、鎖與Spring事務避坑)
一提到 MySQL 事務很多同學第一反應就是背 ACID然后面試官再追一句“具體解決了什么問題”人就卡住了。我當年阿里一面就栽在這題上后來復盤才發(fā)現(xiàn)事務不是用來背的是用來解決真實業(yè)務一致性問題的?；艘恢軙r間把事務相關的實戰(zhàn)場景、底層原理、踩坑記錄重新梳理了一遍這篇就把“為什么用事務”這件事講透并且給你 4 個可以直接套進簡歷和面試回答里的業(yè)務場景。1. 事務的本質(zhì)不是“能用”而是“必須用”很多人對事務的理解停留在“多條 SQL 要么都成功要么都失敗”這個說法沒錯但太淺了。真正的問題是沒有事務的時候業(yè)務到底會壞成什么樣1.1 沒有事務的世界是混亂的先看一個最簡單的轉(zhuǎn)賬場景A 給 B 轉(zhuǎn) 100 元代碼里至少兩條 SQL——扣 A 的余額加 B 的余額。如果這兩條 SQL 之間數(shù)據(jù)庫突然宕機了會發(fā)生什么A 的錢扣了B 的錢沒到。錢憑空消失了。這不是什么極端情況硬件故障、網(wǎng)絡閃斷、進程被殺任意一個都能觸發(fā)。再比如庫存扣減用戶下單時先檢查庫存夠不夠再扣減庫存再創(chuàng)建訂單。這三步如果中間失敗了可能出現(xiàn)庫存扣了但訂單沒創(chuàng)建或者訂單創(chuàng)建了但庫存沒扣。前者導致用戶白付款后者導致超賣。這就是事務存在的根本原因它把一組操作變成一個不可分割的原子單元。這組操作要么全部提交成功要么全部回滾數(shù)據(jù)庫里永遠不會留下“做了一半”的中間狀態(tài)。1.2 事務的邊界就是業(yè)務一致性的邊界面試官問“事務具體解決了什么問題”本質(zhì)上是在考察你能不能識別出業(yè)務里的“一致性邊界”。什么叫一致性邊界就是一組數(shù)據(jù)之間必須維持某種業(yè)務規(guī)則。比如賬戶余額和交易流水必須對得上庫存和訂單必須對得上主表和從表之間外鍵關系不能斷。這些“必須對得上”的規(guī)則就是事務要保護的邊界。事務把邊界內(nèi)的所有操作綁定在一起保證要么全部生效要么全部消失。這不是 MySQL 的獨門絕技而是所有關系型數(shù)據(jù)庫的底線能力。理解了這一點你才能回答“為什么不用 Redis 存訂單 MySQL 存庫存”這類問題——因為 Redis 根本沒有事務的強一致保證而業(yè)務需要。2. 四個必須用事務的經(jīng)典場景直接套我整理了幾個高頻業(yè)務場景每個都是面試官愛問的也是日常開發(fā)真正會用到的。你可以直接用它們的思路回答“事務解決了什么問題”。2.1 場景一下單扣庫存超賣的防線電商下單是最經(jīng)典的事務場景。偽代碼大概是這樣的BEGIN; SELECT stock FROM product WHERE id 1 FOR UPDATE; -- 業(yè)務校驗stock 0 UPDATE product SET stock stock - 1 WHERE id 1; INSERT INTO order (user_id, product_id, amount) VALUES (1001, 1, 99.00); COMMIT;這里事務解決的三個具體問題第一防止超賣。如果兩個請求同時讀到庫存為 1都通過了校驗都執(zhí)行了扣減庫存就變成 -1 了。加了FOR UPDATE行鎖后第二個事務必須等第一個事務提交后才能讀庫存讀到的是 0然后直接返回“庫存不足”。第二保證訂單和庫存數(shù)量一致。如果先創(chuàng)建訂單、后扣庫存扣庫存失敗時訂單已經(jīng)落庫了用戶會看到“有訂單但沒有庫存”的怪事。事務讓這兩步要么都成功要么都失敗后臺對賬永遠不用操心“訂單數(shù) vs 庫存扣減數(shù)”對不上。第三失敗可回滾。當訂單金額校驗失敗、或者支付回調(diào)超時導致訂單需要取消時直接ROLLBACK就能把庫存加回來不需要寫“補償邏輯”。實際注意點庫存扣減不能用SELECT stock THEN UPDATE的“先查后改”方式除非你查詢時加了鎖否則一定會遇到并發(fā)問題。我在項目里見過很多同學寫SELECT stock FROM ...不帶FOR UPDATE然后做 if 判斷壓測一上就超賣。正確做法是直接用原子 UPDATEUPDATE product SET stock stock - 1 WHERE id 1 AND stock 0;影響行數(shù)為 1 表示扣減成功為 0 表示庫存不足。這種方式不需要顯式加行鎖性能更好也更安全。2.2 場景二轉(zhuǎn)賬與資金流水一分錢都不能差轉(zhuǎn)賬和賬戶余額變動是所有金融類系統(tǒng)的命根子。事務在這里解決的不僅是“錢不能丟”還包括“流水不能缺”。BEGIN; UPDATE account SET balance balance - 100 WHERE id A; UPDATE account SET balance balance 100 WHERE id B; INSERT INTO transfer_log (from_id, to_id, amount, status) VALUES (A, B, 100, SUCCESS); COMMIT;事務在這里的核心價值是資金操作與流水記錄的同生共死。如果只更新余額不記錄流水一旦后續(xù)對賬發(fā)現(xiàn)金額不平你根本無法追溯。如果先記流水再改余額流水可能和實際余額不一致。另一個容易被忽略的點是金額操作必須使用balance balance - 100這種相對更新不能先 SELECT 出來再 UPDATE 絕對值。原因和庫存一樣并發(fā)下兩個請求讀到同一個余額各自計算后寫回就會丟更新。同時要小心余額不能為負數(shù)UPDATE account SET balance balance - 100 WHERE id A AND balance 100;影響行數(shù)為 0 就說明余額不足這就利用數(shù)據(jù)庫的行鎖保證了“余額檢查 扣減”是原子的。2.3 場景三并發(fā)搶購/限量發(fā)放防止身份與數(shù)量沖突搶購、優(yōu)惠券限量領取、活動名額搶占這些場景的特點是同一時刻大量并發(fā)請求爭搶有限資源。假設一個活動只發(fā)放 100 張優(yōu)惠券用戶最多領 1 張。代碼邏輯BEGIN; -- 檢查用戶是否已領取 SELECT COUNT(*) FROM coupon_user WHERE user_id 1001 AND activity_id 888; -- 檢查券是否還有剩余 SELECT remaining FROM coupon_activity WHERE id 888 FOR UPDATE; -- 扣減剩余數(shù)量 UPDATE coupon_activity SET remaining remaining - 1 WHERE id 888; -- 插入用戶領取記錄 INSERT INTO coupon_user (user_id, activity_id) VALUES (1001, 888); COMMIT;事務在這里解決的是“唯一性 數(shù)量雙重約束”的并發(fā)一致性問題。如果兩個事務同時查到用戶沒領過、同時插入領取記錄就會有人重復領。解決重復領取有兩種方式數(shù)據(jù)庫唯一索引兜底給(user_id, activity_id)建唯一索引第二次插入直接報 Duplicate Entry。唯一索引 事務配合在一個事務里先查詢再插入配合唯一索引的報錯回滾讓重復領取的操作回滾掉避免數(shù)量被重復扣減。這里要注意依賴“先查后插”在并發(fā)下是不可靠的唯一索引才是最后防線事務負責把數(shù)量扣減和領取記錄綁在一起。2.4 場景四跨表多級寫操作主從數(shù)據(jù)不分離業(yè)務里經(jīng)常有一張主表 多張從表的場景比如創(chuàng)建訂單要寫訂單主表、訂單明細表、訂單狀態(tài)流轉(zhuǎn)表、消息推送表。BEGIN; INSERT INTO order_main (order_no, user_id, amount) VALUES (NO-2025-001, 1001, 99.00); INSERT INTO order_detail (order_no, product_id, price, qty) VALUES (NO-2025-001, 1, 99.00, 1); INSERT INTO order_status_log (order_no, status, remark) VALUES (NO-2025-001, CREATED, 下單成功); INSERT INTO notify_task (biz_id, content, status) VALUES (NO-2025-001, 您的訂單已創(chuàng)建, PENDING); COMMIT;這個場景的事務價值在于多張表的邏輯關系不可分割。如果訂單主表寫入成功明細表插入失敗你會得到一張沒有商品的訂單如果狀態(tài)流轉(zhuǎn)表沒寫入后續(xù)訂單追蹤壞了如果消息表沒寫入用戶收不到通知客服得手工查。事務把這幾張表的寫入變成一個整體任何一步失敗所有表都不會留下臟數(shù)據(jù)。實際開發(fā)中主從表不一致是最難排查的數(shù)據(jù)問題之一因為看起來每條數(shù)據(jù)都像真的但對賬就是不平。多表聯(lián)寫時遵守一條原則主表和它的所有從表必須在同一個事務里完成寫操作。3. 事務的底層原理隔離級別、鎖與日志的配合光知道場景不夠面試官還會問原理。你要能從底層解釋“事務為什么能實現(xiàn)這些保證”核心是三件事隔離級別控制并發(fā)可見性鎖控制資源競爭日志控制持久化與回滾。3.1 隔離級別怎么選決定了并發(fā)能力MySQL 的 InnoDB 引擎默認隔離級別是Repeatable Read可重復讀這也是大家背得最熟的。四種隔離級別對應不同的一致性強度隔離級別臟讀不可重復讀幻讀并發(fā)能力Read Uncommitted可能可能可能最高Read Committed避免可能可能高Repeatable Read避免避免可能InnoDB已解決中Serializable避免避免避免最低臟讀是事務讀到了其他事務未提交的數(shù)據(jù)如果對方回滾你讀到的就是假數(shù)據(jù)。不可重復讀是同一事務里兩次讀同一行結(jié)果不一樣因為別的事務提交了修改?；米x是同一事務里兩次范圍查詢行數(shù)不一樣因為別的事務插入或刪除了行。InnoDB 在 Repeatable Read 下通過 MVCC多版本并發(fā)控制解決了快照讀的幻讀問題又通過間隙鎖解決了當前讀的幻讀問題。所以默認級別下臟讀、不可重復讀、幻讀都能被避免同時保持較高的并發(fā)。注意一個常見誤區(qū)不是隔離級別越高越好。Serializable 最安全但所有讀寫都會串行化并發(fā)掉到零。你要根據(jù)業(yè)務容忍度選級別大部分系統(tǒng)用默認的 RR 就夠了讀多寫少的報表系統(tǒng)甚至可以降到 Read Committed 提升并發(fā)。3.2 undo log 和 redo log事務的雙保險事務能回滾靠的是undo log事務能持久化靠的是redo log。undo log記錄的是“修改前的數(shù)據(jù)”。事務執(zhí)行 UPDATE 時先把舊值寫入 undo log如果事務回滾就用 undo log 把數(shù)據(jù)恢復原樣。這也是 MVCC 實現(xiàn)的核心——不同事務能看到數(shù)據(jù)的不同版本底層就是靠 undo log 鏈。redo log記錄的是“修改后的數(shù)據(jù)”用于崩潰恢復。InnoDB 采用 Write-Ahead LoggingWAL策略先寫 redo log再刷數(shù)據(jù)頁。如果數(shù)據(jù)庫在事務提交后、數(shù)據(jù)落盤前崩潰了重啟后可以用 redo log 把已提交的事務恢復出來。這兩套日志配合回答了面試官愛問的問題“事務提交了但數(shù)據(jù)庫宕機數(shù)據(jù)會丟嗎”答案是不會因為 redo log 里已經(jīng)有記錄。這同時也是 MySQL 主從復制的基礎備庫通過同步主庫的 binlog 來恢復數(shù)據(jù)。3.3 鎖的粒度與選擇影響事務性能的關鍵InnoDB 的鎖分兩種共享鎖S Lock讀鎖和排他鎖X Lock寫鎖。讀寫互斥寫寫互斥讀讀共存。行鎖是 InnoDB 的默認鎖定粒度它還有一個特殊情況間隙鎖Gap Lock。在 RR 隔離級別下當你用范圍條件查詢時InnoDB 不僅鎖住命中行還會鎖住索引之間的間隙防止其他事務插入新行導致幻讀。這里有一個反直覺的知識點即使你的 WHERE 條件沒有命中任何行只要走了索引范圍掃描也會觸發(fā)間隙鎖把整個范圍鎖死。一個常見的死鎖場景是-- 事務A SELECT * FROM product WHERE id BETWEEN 1 AND 100 FOR UPDATE; -- 事務B INSERT INTO product (id, name) VALUES (50, new);事務 B 插入 id50 的記錄時需要獲得間隙鎖而事務 A 持有 1-100 范圍的間隙鎖于是 B 等待。如果事務 A 后面還要插入一條記錄需要 B 的鎖就形成死鎖。排查死鎖時使用SHOW ENGINE INNODB STATUS查看最近一次死鎖信息里面會明確告訴你兩個事務各自持有和等待哪些鎖。死鎖不等于 bug業(yè)務里偶爾發(fā)生是正常的關鍵是讓事務能快速回滾重試而不是永久阻塞。4. Spring 事務實戰(zhàn)注解怎么用才不踩坑日常開發(fā)多數(shù)用Transactional但很多人只知其然不知道這個注解里藏著多少坑。4.1 Transactional 的失效場景逐一排查第一個大坑是自調(diào)用導致事務失效。同一個類里方法 A 調(diào)用方法 BB 上有Transactional但事務不會生效。原因是 Spring 事務基于 AOP 動態(tài)代理代理對象才能攔截方法并開啟事務。自調(diào)用是 this.methodB()走的是原始對象不是代理對象事務攔截器根本感知不到。// 錯誤寫法 Service public class OrderService { public void createOrder() { this.deductStock(); // 自調(diào)用事務失效 } Transactional public void deductStock() { // 這個事務不會生效 } } // 正確寫法1注入自身代理 Autowired private OrderService self; public void createOrder() { self.deductStock(); } // 正確寫法2拆到另一個Service第二個大坑是Transactional 只捕獲 RuntimeException 和 Error不捕獲 checked 異常。如果你的業(yè)務方法顯式拋出 Exception事務默認不會回滾。解決方法是加 rollbackFor 參數(shù)Transactional(rollbackFor Exception.class) public void doSomething() throws Exception { // 業(yè)務邏輯 }第三個坑是事務方法必須被 public 修飾。Spring 官方文檔明確說明代理只能攔截 public 方法protected、private 上的 Transactional 不會生效。4.2 事務傳播行為怎么選Transactional的 propagation 屬性定義了事務的傳播行為常用的幾個傳播行為效果使用場景REQUIRED默認如果已有事務則加入沒有則新建大多數(shù)業(yè)務REQUIRES_NEW總是新建事務掛起外層事務獨立記錄日志NESTED基于 Savepoint 的嵌套事務內(nèi)層失敗只回滾自己批量處理時局部回滾NOT_SUPPORTED以非事務方式執(zhí)行大查詢避免占用連接我踩過最深的一個坑外層事務調(diào)用了內(nèi)層REQUIRES_NEW的方法內(nèi)層事務提交了但外層之后拋異?；貪L內(nèi)層已經(jīng)提交的數(shù)據(jù)不會被回滾。這在一些“先發(fā)消息后改狀態(tài)”的業(yè)務里會讓數(shù)據(jù)不一致。使用 REQUIRES_NEW 前一定要確認這個內(nèi)層操作你希望它獨立于外層事務成功嗎4.3 大事務是性能殺手所謂大事務就是執(zhí)行時間長、操作數(shù)據(jù)量大的事務。比如在一個事務里循環(huán) 10 萬條數(shù)據(jù)做更新整個過程占用連接、持有鎖其他事務全部等待連接池被打滿數(shù)據(jù)庫負載飆升。我見過一個事故某系統(tǒng)凌晨跑批一個事務處理 50 萬條數(shù)據(jù)運行 40 分鐘直接把數(shù)據(jù)庫連接池耗盡線上業(yè)務全部超時。解決思路是批處理按批次提交每 500 條一個事務事務里不要寫遠程調(diào)用、發(fā)消息等耗時操作事務里盡量只做必要的 SQL能挪到事務外的都挪出去。那題“mysql 的事務日志已滿”本質(zhì)上也是大事務的變種。事務日志通常是 undo log 或 redo log被一個長事務占滿數(shù)據(jù)庫無法繼續(xù)分配日志空間會直接報錯。遇到這種情況先殺掉或回滾大事務再檢查日志文件的增長速度。5. 事務常見問題與排查技巧實錄5.1 鎖等待超時與死鎖怎么區(qū)分和應對很多同學遇到Lock wait timeout exceeded默認 50 秒和Deadlock found會慌。這兩個完全不同鎖等待是事務 A 持鎖事務 B 等待A 沒結(jié)束B 等到超時。通常原因一個事務執(zhí)行太久沒提交另一個事務要修改同一行。排查思路先查information_schema.innodb_trx看看有哪些長事務沒提交再查sys.innodb_lock_waits定位具體的阻塞鏈。死鎖是兩個事務互相持有對方需要的鎖數(shù)據(jù)庫檢測到死鎖后會讓其中一個回滾另一個繼續(xù)。死鎖通常發(fā)生在多行更新順序不一致的場景。比如事務 A 先更新訂單再更新庫存事務 B 先更新庫存再更新訂單在并發(fā)下就可能死鎖。解決辦法一是統(tǒng)一多行更新的順序按主鍵或固定字段排序后再更新二是讓事務盡量短減少鎖持有時間三是在業(yè)務層捕獲死鎖異常后重試。5.2 怎么定位一個事務里到底干了什么線上排查事務問題最實用的方式開啟 general log 或者用 Performance Schema 查看當前執(zhí)行的語句-- 查看當前所有事務 SELECT * FROM information_schema.innodb_trx; -- 查看鎖等待情況 SELECT * FROM sys.innodb_lock_waits; -- 查看正在執(zhí)行的SQL SELECT * FROM performance_schema.events_statements_current;這三個查詢組合起來基本能回答“誰持有鎖”“誰在等鎖”“卡了多久”。我在實際排查中80% 的事務問題是長事務和慢 SQL 疊加導致的用這三條語句就能快速定位。5.3 分布式事務別動不動就上面試官很容易追問分布式事務。你要清楚分布式事務不是在本地事務之外另搞一套而是把多個數(shù)據(jù)源的操作納入同一個一致性協(xié)議。常見的方案有兩階段提交2PC性能差協(xié)調(diào)者單點實際生產(chǎn)用得少。本地消息表在自己庫里建消息表業(yè)務操作和消息寫入同事務由異步任務投遞消息。這是最實用的方案成本低可靠性高。事務消息如 RocketMQ通過 MQ 的半消息機制保證本地事務和消息發(fā)送的原子性。TCCTry-Confirm-Cancel性能好、侵入性強適合高并發(fā)場景。我的建議是優(yōu)先考慮能否把數(shù)據(jù)源合并到同一個庫比如把訂單和庫存放同一個 MySQL 實例用本地事務解決實在拆不開再考慮本地消息表方案它是投入產(chǎn)出比最高的。我在一個小項目里就踩過分布式事務的坑剛開始微服務拆得很細訂單服務和庫存服務各用一個庫訂單創(chuàng)建時要調(diào)庫存服務扣減兩邊的數(shù)據(jù)根本沒法用本地事務保證一致。后來把兩個表合并到同一個庫用本地事務 消息表就解決了成本和維護難度都大幅下降。6. 實操總結(jié)事務工具包與避坑清單最后把日常開發(fā)最有用的一組實操要點集中列一下方便你直接抄作業(yè)。6.1 事務編碼自查清單[ ] 事務方法必須是 public且不能自調(diào)用[ ]Transactional指定rollbackFor Exception.class別用默認值[ ] 事務里的 SQL 不允許遠程調(diào)用、IO 操作、大循環(huán)[ ] 寫操作必須用相對更新SET balance balance - 100不要先查后改[ ] 唯一性約束靠數(shù)據(jù)庫唯一索引兜底別依賴業(yè)務代碼判斷[ ] 多行更新統(tǒng)一順序避免死鎖[ ] 批處理按批次提交每批次不要超過 500~1000 條[ ] 事務提交后立即釋放連接盡快歸還連接池。6.2 面試回答模板如果面試官問“為什么用 MySQL 事務具體解決了什么問題”你可以這樣組織回答“事務解決的核心問題是一組業(yè)務操作要么全部生效要么全部回滾。具體到場景上第一是訂單和庫存的一致性防止超賣和半截數(shù)據(jù)第二是資金操作和流水的綁定防止賬實不符第三是并發(fā)場景下的資源競爭通過鎖和隔離級別保證操作互不干擾第四是多表聯(lián)寫的主從一致性。底層靠 undo log 實現(xiàn)回滾redo log 實現(xiàn)持久化MVCC 和鎖實現(xiàn)并發(fā)控制隔離級別則是在一致性和性能之間做權(quán)衡。”這一套回答既有場景、又有原理、還帶權(quán)衡比單純背 ACID 強得多。6.3 小技巧事務里如何優(yōu)雅處理“業(yè)務校驗失敗”實際開發(fā)里事務里經(jīng)常要抽“余額是否足夠”“庫存是否充足”這樣的校驗。我的建議是讓數(shù)據(jù)庫來兜底業(yè)務規(guī)則。比如庫存扣減用stock 0條件余額扣減用balance 100條件。條件不滿足時 UPDATE 影響行數(shù)為 0業(yè)務層判斷后拋出異常觸發(fā)回滾。這樣做比“先 SELECT 再 if 判斷”更安全也減少一次查詢和一次鎖競爭。我個人在實際操作中最深的一條教訓是事務本身不解決業(yè)務邏輯問題它只是保證并發(fā)下的數(shù)據(jù)一致性底線。真正決定事務好不好的是你把什么東西放進了事務、用什么條件約束數(shù)據(jù)。把這一層想清楚所有事務相關的面試題和線上問題你都會有清晰的解題思路。 MySQL事務實戰(zhàn)：從ACID到隔離級別、鎖與Spring事務避坑
一提到 MySQL 事務很多同學第一反應就是背 ACID然后面試官再追一句“具體解決了什么問題”人就卡住了。我當年阿里一面就栽在這題上后來復盤才發(fā)現(xiàn)事務不是用來背的是用來解決真實業(yè)務一致性問題的?；艘恢軙r間把事務相關的實戰(zhàn)場景、底層原理、踩坑記錄重新梳理了一遍這篇就把“為什么用事務”這件事講透并且給你 4 個可以直接套進簡歷和面試回答里的業(yè)務場景。1. 事務的本質(zhì)不是“能用”而是“必須用”很多人對事務的理解停留在“多條 SQL 要么都成功要么都失敗”這個說法沒錯但太淺了。真正的問題是沒有事務的時候業(yè)務到底會壞成什么樣1.1 沒有事務的世界是混亂的先看一個最簡單的轉(zhuǎn)賬場景A 給 B 轉(zhuǎn) 100 元代碼里至少兩條 SQL——扣 A 的余額加 B 的余額。如果這兩條 SQL 之間數(shù)據(jù)庫突然宕機了會發(fā)生什么A 的錢扣了B 的錢沒到。錢憑空消失了。這不是什么極端情況硬件故障、網(wǎng)絡閃斷、進程被殺任意一個都能觸發(fā)。再比如庫存扣減用戶下單時先檢查庫存夠不夠再扣減庫存再創(chuàng)建訂單。這三步如果中間失敗了可能出現(xiàn)庫存扣了但訂單沒創(chuàng)建或者訂單創(chuàng)建了但庫存沒扣。前者導致用戶白付款后者導致超賣。這就是事務存在的根本原因它把一組操作變成一個不可分割的原子單元。這組操作要么全部提交成功要么全部回滾數(shù)據(jù)庫里永遠不會留下“做了一半”的中間狀態(tài)。1.2 事務的邊界就是業(yè)務一致性的邊界面試官問“事務具體解決了什么問題”本質(zhì)上是在考察你能不能識別出業(yè)務里的“一致性邊界”。什么叫一致性邊界就是一組數(shù)據(jù)之間必須維持某種業(yè)務規(guī)則。比如賬戶余額和交易流水必須對得上庫存和訂單必須對得上主表和從表之間外鍵關系不能斷。這些“必須對得上”的規(guī)則就是事務要保護的邊界。事務把邊界內(nèi)的所有操作綁定在一起保證要么全部生效要么全部消失。這不是 MySQL 的獨門絕技而是所有關系型數(shù)據(jù)庫的底線能力。理解了這一點你才能回答“為什么不用 Redis 存訂單 MySQL 存庫存”這類問題——因為 Redis 根本沒有事務的強一致保證而業(yè)務需要。2. 四個必須用事務的經(jīng)典場景直接套我整理了幾個高頻業(yè)務場景每個都是面試官愛問的也是日常開發(fā)真正會用到的。你可以直接用它們的思路回答“事務解決了什么問題”。2.1 場景一下單扣庫存超賣的防線電商下單是最經(jīng)典的事務場景。偽代碼大概是這樣的BEGIN; SELECT stock FROM product WHERE id 1 FOR UPDATE; -- 業(yè)務校驗stock 0 UPDATE product SET stock stock - 1 WHERE id 1; INSERT INTO order (user_id, product_id, amount) VALUES (1001, 1, 99.00); COMMIT;這里事務解決的三個具體問題第一防止超賣。如果兩個請求同時讀到庫存為 1都通過了校驗都執(zhí)行了扣減庫存就變成 -1 了。加了FOR UPDATE行鎖后第二個事務必須等第一個事務提交后才能讀庫存讀到的是 0然后直接返回“庫存不足”。第二保證訂單和庫存數(shù)量一致。如果先創(chuàng)建訂單、后扣庫存扣庫存失敗時訂單已經(jīng)落庫了用戶會看到“有訂單但沒有庫存”的怪事。事務讓這兩步要么都成功要么都失敗后臺對賬永遠不用操心“訂單數(shù) vs 庫存扣減數(shù)”對不上。第三失敗可回滾。當訂單金額校驗失敗、或者支付回調(diào)超時導致訂單需要取消時直接ROLLBACK就能把庫存加回來不需要寫“補償邏輯”。實際注意點庫存扣減不能用SELECT stock THEN UPDATE的“先查后改”方式除非你查詢時加了鎖否則一定會遇到并發(fā)問題。我在項目里見過很多同學寫SELECT stock FROM ...不帶FOR UPDATE然后做 if 判斷壓測一上就超賣。正確做法是直接用原子 UPDATEUPDATE product SET stock stock - 1 WHERE id 1 AND stock 0;影響行數(shù)為 1 表示扣減成功為 0 表示庫存不足。這種方式不需要顯式加行鎖性能更好也更安全。2.2 場景二轉(zhuǎn)賬與資金流水一分錢都不能差轉(zhuǎn)賬和賬戶余額變動是所有金融類系統(tǒng)的命根子。事務在這里解決的不僅是“錢不能丟”還包括“流水不能缺”。BEGIN; UPDATE account SET balance balance - 100 WHERE id A; UPDATE account SET balance balance 100 WHERE id B; INSERT INTO transfer_log (from_id, to_id, amount, status) VALUES (A, B, 100, SUCCESS); COMMIT;事務在這里的核心價值是資金操作與流水記錄的同生共死。如果只更新余額不記錄流水一旦后續(xù)對賬發(fā)現(xiàn)金額不平你根本無法追溯。如果先記流水再改余額流水可能和實際余額不一致。另一個容易被忽略的點是金額操作必須使用balance balance - 100這種相對更新不能先 SELECT 出來再 UPDATE 絕對值。原因和庫存一樣并發(fā)下兩個請求讀到同一個余額各自計算后寫回就會丟更新。同時要小心余額不能為負數(shù)UPDATE account SET balance balance - 100 WHERE id A AND balance 100;影響行數(shù)為 0 就說明余額不足這就利用數(shù)據(jù)庫的行鎖保證了“余額檢查 扣減”是原子的。2.3 場景三并發(fā)搶購/限量發(fā)放防止身份與數(shù)量沖突搶購、優(yōu)惠券限量領取、活動名額搶占這些場景的特點是同一時刻大量并發(fā)請求爭搶有限資源。假設一個活動只發(fā)放 100 張優(yōu)惠券用戶最多領 1 張。代碼邏輯BEGIN; -- 檢查用戶是否已領取 SELECT COUNT(*) FROM coupon_user WHERE user_id 1001 AND activity_id 888; -- 檢查券是否還有剩余 SELECT remaining FROM coupon_activity WHERE id 888 FOR UPDATE; -- 扣減剩余數(shù)量 UPDATE coupon_activity SET remaining remaining - 1 WHERE id 888; -- 插入用戶領取記錄 INSERT INTO coupon_user (user_id, activity_id) VALUES (1001, 888); COMMIT;事務在這里解決的是“唯一性 數(shù)量雙重約束”的并發(fā)一致性問題。如果兩個事務同時查到用戶沒領過、同時插入領取記錄就會有人重復領。解決重復領取有兩種方式數(shù)據(jù)庫唯一索引兜底給(user_id, activity_id)建唯一索引第二次插入直接報 Duplicate Entry。唯一索引 事務配合在一個事務里先查詢再插入配合唯一索引的報錯回滾讓重復領取的操作回滾掉避免數(shù)量被重復扣減。這里要注意依賴“先查后插”在并發(fā)下是不可靠的唯一索引才是最后防線事務負責把數(shù)量扣減和領取記錄綁在一起。2.4 場景四跨表多級寫操作主從數(shù)據(jù)不分離業(yè)務里經(jīng)常有一張主表 多張從表的場景比如創(chuàng)建訂單要寫訂單主表、訂單明細表、訂單狀態(tài)流轉(zhuǎn)表、消息推送表。BEGIN; INSERT INTO order_main (order_no, user_id, amount) VALUES (NO-2025-001, 1001, 99.00); INSERT INTO order_detail (order_no, product_id, price, qty) VALUES (NO-2025-001, 1, 99.00, 1); INSERT INTO order_status_log (order_no, status, remark) VALUES (NO-2025-001, CREATED, 下單成功); INSERT INTO notify_task (biz_id, content, status) VALUES (NO-2025-001, 您的訂單已創(chuàng)建, PENDING); COMMIT;這個場景的事務價值在于多張表的邏輯關系不可分割。如果訂單主表寫入成功明細表插入失敗你會得到一張沒有商品的訂單如果狀態(tài)流轉(zhuǎn)表沒寫入后續(xù)訂單追蹤壞了如果消息表沒寫入用戶收不到通知客服得手工查。事務把這幾張表的寫入變成一個整體任何一步失敗所有表都不會留下臟數(shù)據(jù)。實際開發(fā)中主從表不一致是最難排查的數(shù)據(jù)問題之一因為看起來每條數(shù)據(jù)都像真的但對賬就是不平。多表聯(lián)寫時遵守一條原則主表和它的所有從表必須在同一個事務里完成寫操作。3. 事務的底層原理隔離級別、鎖與日志的配合光知道場景不夠面試官還會問原理。你要能從底層解釋“事務為什么能實現(xiàn)這些保證”核心是三件事隔離級別控制并發(fā)可見性鎖控制資源競爭日志控制持久化與回滾。3.1 隔離級別怎么選決定了并發(fā)能力MySQL 的 InnoDB 引擎默認隔離級別是Repeatable Read可重復讀這也是大家背得最熟的。四種隔離級別對應不同的一致性強度隔離級別臟讀不可重復讀幻讀并發(fā)能力Read Uncommitted可能可能可能最高Read Committed避免可能可能高Repeatable Read避免避免可能InnoDB已解決中Serializable避免避免避免最低臟讀是事務讀到了其他事務未提交的數(shù)據(jù)如果對方回滾你讀到的就是假數(shù)據(jù)。不可重復讀是同一事務里兩次讀同一行結(jié)果不一樣因為別的事務提交了修改?；米x是同一事務里兩次范圍查詢行數(shù)不一樣因為別的事務插入或刪除了行。InnoDB 在 Repeatable Read 下通過 MVCC多版本并發(fā)控制解決了快照讀的幻讀問題又通過間隙鎖解決了當前讀的幻讀問題。所以默認級別下臟讀、不可重復讀、幻讀都能被避免同時保持較高的并發(fā)。注意一個常見誤區(qū)不是隔離級別越高越好。Serializable 最安全但所有讀寫都會串行化并發(fā)掉到零。你要根據(jù)業(yè)務容忍度選級別大部分系統(tǒng)用默認的 RR 就夠了讀多寫少的報表系統(tǒng)甚至可以降到 Read Committed 提升并發(fā)。3.2 undo log 和 redo log事務的雙保險事務能回滾靠的是undo log事務能持久化靠的是redo log。undo log記錄的是“修改前的數(shù)據(jù)”。事務執(zhí)行 UPDATE 時先把舊值寫入 undo log如果事務回滾就用 undo log 把數(shù)據(jù)恢復原樣。這也是 MVCC 實現(xiàn)的核心——不同事務能看到數(shù)據(jù)的不同版本底層就是靠 undo log 鏈。redo log記錄的是“修改后的數(shù)據(jù)”用于崩潰恢復。InnoDB 采用 Write-Ahead LoggingWAL策略先寫 redo log再刷數(shù)據(jù)頁。如果數(shù)據(jù)庫在事務提交后、數(shù)據(jù)落盤前崩潰了重啟后可以用 redo log 把已提交的事務恢復出來。這兩套日志配合回答了面試官愛問的問題“事務提交了但數(shù)據(jù)庫宕機數(shù)據(jù)會丟嗎”答案是不會因為 redo log 里已經(jīng)有記錄。這同時也是 MySQL 主從復制的基礎備庫通過同步主庫的 binlog 來恢復數(shù)據(jù)。3.3 鎖的粒度與選擇影響事務性能的關鍵InnoDB 的鎖分兩種共享鎖S Lock讀鎖和排他鎖X Lock寫鎖。讀寫互斥寫寫互斥讀讀共存。行鎖是 InnoDB 的默認鎖定粒度它還有一個特殊情況間隙鎖Gap Lock。在 RR 隔離級別下當你用范圍條件查詢時InnoDB 不僅鎖住命中行還會鎖住索引之間的間隙防止其他事務插入新行導致幻讀。這里有一個反直覺的知識點即使你的 WHERE 條件沒有命中任何行只要走了索引范圍掃描也會觸發(fā)間隙鎖把整個范圍鎖死。一個常見的死鎖場景是-- 事務A SELECT * FROM product WHERE id BETWEEN 1 AND 100 FOR UPDATE; -- 事務B INSERT INTO product (id, name) VALUES (50, new);事務 B 插入 id50 的記錄時需要獲得間隙鎖而事務 A 持有 1-100 范圍的間隙鎖于是 B 等待。如果事務 A 后面還要插入一條記錄需要 B 的鎖就形成死鎖。排查死鎖時使用SHOW ENGINE INNODB STATUS查看最近一次死鎖信息里面會明確告訴你兩個事務各自持有和等待哪些鎖。死鎖不等于 bug業(yè)務里偶爾發(fā)生是正常的關鍵是讓事務能快速回滾重試而不是永久阻塞。4. Spring 事務實戰(zhàn)注解怎么用才不踩坑日常開發(fā)多數(shù)用Transactional但很多人只知其然不知道這個注解里藏著多少坑。4.1 Transactional 的失效場景逐一排查第一個大坑是自調(diào)用導致事務失效。同一個類里方法 A 調(diào)用方法 BB 上有Transactional但事務不會生效。原因是 Spring 事務基于 AOP 動態(tài)代理代理對象才能攔截方法并開啟事務。自調(diào)用是 this.methodB()走的是原始對象不是代理對象事務攔截器根本感知不到。// 錯誤寫法 Service public class OrderService { public void createOrder() { this.deductStock(); // 自調(diào)用事務失效 } Transactional public void deductStock() { // 這個事務不會生效 } } // 正確寫法1注入自身代理 Autowired private OrderService self; public void createOrder() { self.deductStock(); } // 正確寫法2拆到另一個Service第二個大坑是Transactional 只捕獲 RuntimeException 和 Error不捕獲 checked 異常。如果你的業(yè)務方法顯式拋出 Exception事務默認不會回滾。解決方法是加 rollbackFor 參數(shù)Transactional(rollbackFor Exception.class) public void doSomething() throws Exception { // 業(yè)務邏輯 }第三個坑是事務方法必須被 public 修飾。Spring 官方文檔明確說明代理只能攔截 public 方法protected、private 上的 Transactional 不會生效。4.2 事務傳播行為怎么選Transactional的 propagation 屬性定義了事務的傳播行為常用的幾個傳播行為效果使用場景REQUIRED默認如果已有事務則加入沒有則新建大多數(shù)業(yè)務REQUIRES_NEW總是新建事務掛起外層事務獨立記錄日志NESTED基于 Savepoint 的嵌套事務內(nèi)層失敗只回滾自己批量處理時局部回滾NOT_SUPPORTED以非事務方式執(zhí)行大查詢避免占用連接我踩過最深的一個坑外層事務調(diào)用了內(nèi)層REQUIRES_NEW的方法內(nèi)層事務提交了但外層之后拋異?；貪L內(nèi)層已經(jīng)提交的數(shù)據(jù)不會被回滾。這在一些“先發(fā)消息后改狀態(tài)”的業(yè)務里會讓數(shù)據(jù)不一致。使用 REQUIRES_NEW 前一定要確認這個內(nèi)層操作你希望它獨立于外層事務成功嗎4.3 大事務是性能殺手所謂大事務就是執(zhí)行時間長、操作數(shù)據(jù)量大的事務。比如在一個事務里循環(huán) 10 萬條數(shù)據(jù)做更新整個過程占用連接、持有鎖其他事務全部等待連接池被打滿數(shù)據(jù)庫負載飆升。我見過一個事故某系統(tǒng)凌晨跑批一個事務處理 50 萬條數(shù)據(jù)運行 40 分鐘直接把數(shù)據(jù)庫連接池耗盡線上業(yè)務全部超時。解決思路是批處理按批次提交每 500 條一個事務事務里不要寫遠程調(diào)用、發(fā)消息等耗時操作事務里盡量只做必要的 SQL能挪到事務外的都挪出去。那題“mysql 的事務日志已滿”本質(zhì)上也是大事務的變種。事務日志通常是 undo log 或 redo log被一個長事務占滿數(shù)據(jù)庫無法繼續(xù)分配日志空間會直接報錯。遇到這種情況先殺掉或回滾大事務再檢查日志文件的增長速度。5. 事務常見問題與排查技巧實錄5.1 鎖等待超時與死鎖怎么區(qū)分和應對很多同學遇到Lock wait timeout exceeded默認 50 秒和Deadlock found會慌。這兩個完全不同鎖等待是事務 A 持鎖事務 B 等待A 沒結(jié)束B 等到超時。通常原因一個事務執(zhí)行太久沒提交另一個事務要修改同一行。排查思路先查information_schema.innodb_trx看看有哪些長事務沒提交再查sys.innodb_lock_waits定位具體的阻塞鏈。死鎖是兩個事務互相持有對方需要的鎖數(shù)據(jù)庫檢測到死鎖后會讓其中一個回滾另一個繼續(xù)。死鎖通常發(fā)生在多行更新順序不一致的場景。比如事務 A 先更新訂單再更新庫存事務 B 先更新庫存再更新訂單在并發(fā)下就可能死鎖。解決辦法一是統(tǒng)一多行更新的順序按主鍵或固定字段排序后再更新二是讓事務盡量短減少鎖持有時間三是在業(yè)務層捕獲死鎖異常后重試。5.2 怎么定位一個事務里到底干了什么線上排查事務問題最實用的方式開啟 general log 或者用 Performance Schema 查看當前執(zhí)行的語句-- 查看當前所有事務 SELECT * FROM information_schema.innodb_trx; -- 查看鎖等待情況 SELECT * FROM sys.innodb_lock_waits; -- 查看正在執(zhí)行的SQL SELECT * FROM performance_schema.events_statements_current;這三個查詢組合起來基本能回答“誰持有鎖”“誰在等鎖”“卡了多久”。我在實際排查中80% 的事務問題是長事務和慢 SQL 疊加導致的用這三條語句就能快速定位。5.3 分布式事務別動不動就上面試官很容易追問分布式事務。你要清楚分布式事務不是在本地事務之外另搞一套而是把多個數(shù)據(jù)源的操作納入同一個一致性協(xié)議。常見的方案有兩階段提交2PC性能差協(xié)調(diào)者單點實際生產(chǎn)用得少。本地消息表在自己庫里建消息表業(yè)務操作和消息寫入同事務由異步任務投遞消息。這是最實用的方案成本低可靠性高。事務消息如 RocketMQ通過 MQ 的半消息機制保證本地事務和消息發(fā)送的原子性。TCCTry-Confirm-Cancel性能好、侵入性強適合高并發(fā)場景。我的建議是優(yōu)先考慮能否把數(shù)據(jù)源合并到同一個庫比如把訂單和庫存放同一個 MySQL 實例用本地事務解決實在拆不開再考慮本地消息表方案它是投入產(chǎn)出比最高的。我在一個小項目里就踩過分布式事務的坑剛開始微服務拆得很細訂單服務和庫存服務各用一個庫訂單創(chuàng)建時要調(diào)庫存服務扣減兩邊的數(shù)據(jù)根本沒法用本地事務保證一致。后來把兩個表合并到同一個庫用本地事務 消息表就解決了成本和維護難度都大幅下降。6. 實操總結(jié)事務工具包與避坑清單最后把日常開發(fā)最有用的一組實操要點集中列一下方便你直接抄作業(yè)。6.1 事務編碼自查清單[ ] 事務方法必須是 public且不能自調(diào)用[ ]Transactional指定rollbackFor Exception.class別用默認值[ ] 事務里的 SQL 不允許遠程調(diào)用、IO 操作、大循環(huán)[ ] 寫操作必須用相對更新SET balance balance - 100不要先查后改[ ] 唯一性約束靠數(shù)據(jù)庫唯一索引兜底別依賴業(yè)務代碼判斷[ ] 多行更新統(tǒng)一順序避免死鎖[ ] 批處理按批次提交每批次不要超過 500~1000 條[ ] 事務提交后立即釋放連接盡快歸還連接池。6.2 面試回答模板如果面試官問“為什么用 MySQL 事務具體解決了什么問題”你可以這樣組織回答“事務解決的核心問題是一組業(yè)務操作要么全部生效要么全部回滾。具體到場景上第一是訂單和庫存的一致性防止超賣和半截數(shù)據(jù)第二是資金操作和流水的綁定防止賬實不符第三是并發(fā)場景下的資源競爭通過鎖和隔離級別保證操作互不干擾第四是多表聯(lián)寫的主從一致性。底層靠 undo log 實現(xiàn)回滾redo log 實現(xiàn)持久化MVCC 和鎖實現(xiàn)并發(fā)控制隔離級別則是在一致性和性能之間做權(quán)衡。”這一套回答既有場景、又有原理、還帶權(quán)衡比單純背 ACID 強得多。6.3 小技巧事務里如何優(yōu)雅處理“業(yè)務校驗失敗”實際開發(fā)里事務里經(jīng)常要抽“余額是否足夠”“庫存是否充足”這樣的校驗。我的建議是讓數(shù)據(jù)庫來兜底業(yè)務規(guī)則。比如庫存扣減用stock 0條件余額扣減用balance 100條件。條件不滿足時 UPDATE 影響行數(shù)為 0業(yè)務層判斷后拋出異常觸發(fā)回滾。這樣做比“先 SELECT 再 if 判斷”更安全也減少一次查詢和一次鎖競爭。我個人在實際操作中最深的一條教訓是事務本身不解決業(yè)務邏輯問題它只是保證并發(fā)下的數(shù)據(jù)一致性底線。真正決定事務好不好的是你把什么東西放進了事務、用什么條件約束數(shù)據(jù)。把這一層想清楚所有事務相關的面試題和線上問題你都會有清晰的解題思路。