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