事務(wù)這玩意兒做 MySQL 開發(fā)的基本天天都在見但真要說清楚“隔離級(jí)別到底是什么、每個(gè)級(jí)別擋住哪些問題、線上又該配成哪個(gè)”不少干了三五年的朋友也未必能一次講明白。這篇文章我就把這套東西從頭拆到尾不繞彎子從 ACID 講到鎖和 MVCC再把四種隔離級(jí)別逐一過一遍最后用我實(shí)際排過的一個(gè)故障案例收尾。不管你是剛學(xué)數(shù)據(jù)庫(kù)的新手還是準(zhǔn)備系統(tǒng)梳理一遍的資深開發(fā)照著看下來應(yīng)該都能有收獲。1. 先把事務(wù)和 ACID 講清楚——后面所有結(jié)論都建立在這上面1.1 事務(wù)到底是個(gè)什么“東西”數(shù)據(jù)庫(kù)里的事務(wù)可以理解為一組要么全成功、要么全失敗的操作。它解決的核心問題很簡(jiǎn)單多個(gè)步驟的原子一致性。舉個(gè)最典型的轉(zhuǎn)賬場(chǎng)景A 賬戶扣 100B 賬戶加 100。這兩條 SQL 必須作為一個(gè)整體提交如果第一條成功、第二條失敗賬就平不了這是任何系統(tǒng)都不能接受的。MySQL 中使用事務(wù)的姿勢(shì)絕大多數(shù)項(xiàng)目里長(zhǎng)這樣START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;如果中途發(fā)現(xiàn)余額不足、賬戶凍結(jié)之類的問題就用ROLLBACK回滾。InnoDB 之所以能回滾已經(jīng)執(zhí)行過的 UPDATE是因?yàn)樗趦?nèi)存里有 undo log 的機(jī)制每一行改前改后的版本都留著后面講 MVCC 的時(shí)候會(huì)再碰它。值得注意的一個(gè)點(diǎn)是MySQL 里不是所有引擎都支持事務(wù)?，F(xiàn)在的項(xiàng)目默認(rèn)基本都是 InnoDB事務(wù)、外鍵這些都是 InnoDB 的活MyISAM 這類老引擎是沒有事務(wù)的別說回滾了連行鎖都沒有。所以你在討論事務(wù)的時(shí)候默認(rèn)語(yǔ)境就是 InnoDB。1.2 ACID 四個(gè)特性不是擺設(shè)每個(gè)都有對(duì)應(yīng)機(jī)制ACID 是事務(wù)的四個(gè)基本屬性很多人能背出這四個(gè)字母但未必清楚它們分別由什么來保證特性含義InnoDB 的主要保證手段A 原子性事務(wù)內(nèi)的操作要么全部成功要么全部失敗undo log回滾日志C 一致性事務(wù)前后數(shù)據(jù)滿足所有約束總量守恒應(yīng)用邏輯 數(shù)據(jù)庫(kù)約束 其余三個(gè)特性配合I 隔離性并發(fā)事務(wù)之間互相不干擾鎖 MVCCD 持久性事務(wù)提交后數(shù)據(jù)不丟失redo log重做日志我見過不少同學(xué)把一致性和隔離性搞混。一致性其實(shí)是個(gè)更高層的概念數(shù)據(jù)庫(kù)的一致性依賴約束、觸發(fā)器更重要的是依賴應(yīng)用自己去保證業(yè)務(wù)邏輯正確事務(wù)的其他三個(gè)特性都是在幫這個(gè)目標(biāo)服務(wù)。也就是說ACID 是“A、I、D 三個(gè)特性共同支撐起 C”。你得理解這個(gè)關(guān)系后面分析隔離級(jí)別為什么會(huì)有取舍的時(shí)候才不會(huì)懵。InnoDB 在提交事務(wù)時(shí)會(huì)把 redo log 刷到磁盤然后才返回客戶端提交成功。redo log 是順序?qū)懙乃孕阅荛_銷比隨機(jī)寫數(shù)據(jù)文件小很多。萬(wàn)一數(shù)據(jù)庫(kù)崩潰重啟后可以根據(jù) redo log 重放所有已提交的修改這就保證了持久性。前面還有個(gè)細(xì)節(jié)參數(shù)innodb_flush_log_at_trx_commit如果設(shè)為 0 或 2性能會(huì)提升但可能丟失最近 1 秒內(nèi)的日志這是很多 DBA 在性能和數(shù)據(jù)安全之間做權(quán)衡的開關(guān)。2. 并發(fā)不隔離會(huì)出什么事——先認(rèn)識(shí)逃不掉的三類問題2.1 臟讀、不可重復(fù)讀、幻讀一個(gè)比一個(gè)隱蔽討論隔離級(jí)別之前得先把并發(fā)讀寫時(shí)可能出現(xiàn)的四種現(xiàn)象講清楚。別看網(wǎng)上定義一堆其實(shí)展開成因很簡(jiǎn)單。臟讀事務(wù) A 修改了一條數(shù)據(jù)但還沒提交事務(wù) B 讀到了這次未提交的修改。如果 A 后面回滾了B 拿到的是個(gè)不存在過的數(shù)據(jù)這就是“臟數(shù)據(jù)”。讀未提交級(jí)別就允許這種操作實(shí)際項(xiàng)目中幾乎沒人敢用。不可重復(fù)讀同一個(gè)事務(wù)內(nèi)兩次執(zhí)行同樣的 SELECT讀到的結(jié)果不一樣。問題出在另一個(gè)事務(wù)在這兩次查詢之間提交了 UPDATE 并改掉了同一行數(shù)據(jù)。比如你查訂單金額是 100另一個(gè)事務(wù)馬上把它改成 200 并提交你再查一次就變成 200 了。你把第一筆結(jié)果拿去發(fā)獎(jiǎng)勵(lì)第二筆拿去對(duì)賬數(shù)據(jù)就對(duì)不齊?；米x同樣是在一個(gè)事務(wù)內(nèi)查兩次但這次不是某一行變了而是結(jié)果集的行數(shù)變了。比如第一次查滿足statuspending的訂單有 10 條事務(wù)還沒結(jié)束另一個(gè)事務(wù)插入了一條新 pending 訂單并提交你再查就多了一條。這個(gè)多出來的行就像“幻影”一樣所以叫幻讀。還有一個(gè)高頻問題叫丟失更新兩個(gè)事務(wù)同時(shí)讀取同一條記錄各自基于舊值做計(jì)算都去 UPDATE 提交。后提交的會(huì)把先提交的結(jié)果覆蓋掉前一個(gè)事務(wù)的邏輯就白算了。嚴(yán)格來說這個(gè)問題不屬于隔離級(jí)別單獨(dú)造成的MySQL 默認(rèn)的可重復(fù)讀下也可能出現(xiàn)它本質(zhì)上是并發(fā)更新的沖突問題通?？考渔i或版本號(hào)來解決。2.2 這三個(gè)坑在真實(shí)業(yè)務(wù)里是什么樣子很多新手覺得這些現(xiàn)象是理論概念現(xiàn)實(shí)中遇不到。實(shí)際上我做過的一個(gè)活動(dòng)系統(tǒng)就踩過不可重復(fù)讀的坑。當(dāng)時(shí)有個(gè)功能是判斷用戶賬戶余額是否達(dá)到提現(xiàn)門檻事務(wù)里先讀一次余額做判斷中間用戶又充值了然后再讀一次做二次校驗(yàn)。同一個(gè)事務(wù)里面兩次余額不一致導(dǎo)致邏輯分支亂套最后我用顯式加鎖才把問題壓下去。真實(shí)業(yè)務(wù)里這些問題并不是一定出現(xiàn)它取決于并發(fā)時(shí)序和具體隔離級(jí)別。但一旦出現(xiàn)排查成本和業(yè)務(wù)損失都比較大。特別是涉及金額、庫(kù)存、狀態(tài)機(jī)這類關(guān)鍵數(shù)據(jù)對(duì)隔離性的理解必須到位。這也是為什么大多數(shù)項(xiàng)目寧愿犧牲一點(diǎn)點(diǎn)并發(fā)能力也要把隔離級(jí)別定在比較安全的位置。3. MySQL 底層到底怎么兜底的——鎖與 MVCC 的雙人舞3.1 InnoDB 的行鎖和間隙鎖先把它們分開InnoDB 的鎖不是鎖住整張表而是盡量鎖行。按鎖的粒度分主要有三類記錄鎖Record Lock鎖住索引上的一條記錄SELECT ... FOR UPDATE走主鍵或唯一索引時(shí)就是記錄鎖。間隙鎖Gap Lock鎖住兩個(gè)索引鍵之間的“空隙”防止其他事務(wù)在這個(gè)區(qū)間里插入新記錄。臨鍵鎖Next-Key Lock記錄鎖 間隙鎖的組合鎖住一個(gè)左開右閉的區(qū)間。集合上面三類去看幻讀就容易理解了要防止事務(wù) A 查出來 10 條 pending 訂單之后卻有新 pending 訂單插進(jìn)來就必須鎖住“這個(gè)查詢能覆蓋到的索引范圍和相鄰空隙”讓別的事務(wù)沒法在這個(gè)區(qū)間插入新數(shù)據(jù)。這就是臨鍵鎖在做的事。不過注意間隙鎖只在特定隔離級(jí)別下才生效。InnoDB 默認(rèn)的可重復(fù)讀REPEATABLE READ會(huì)加臨鍵鎖來防幻讀如果換成讀已提交READ COMMITTED間隙鎖就基本失效了只剩記錄鎖這樣幻讀又可能回來。Oracle 默認(rèn)隔離級(jí)別是讀已提交也是因?yàn)樗縿e的機(jī)制防了部分問題MySQL 的可重復(fù)讀里防幻讀主要靠鎖加 MVCC 雙管齊下。3.2 MVCC 快照讀不加鎖也能讀到一致快照MVCC全稱是多版本并發(fā)控制你可以把它理解成“數(shù)據(jù)庫(kù)內(nèi)存了行數(shù)據(jù)的多個(gè)歷史版本”。每條記錄除了業(yè)務(wù)字段InnoDB 還額外維護(hù)了DB_TRX_ID最后修改事務(wù)ID和DB_ROLL_PTR回滾指針之類的隱藏列undo log 里保存著舊版本。普通 SELECT 走的是快照讀它不直接鎖當(dāng)前數(shù)據(jù)而是根據(jù)當(dāng)前事務(wù)的快照讀取某個(gè)可見版本。這個(gè)“可見性”是有規(guī)則的大致來說在自己事務(wù)開始之前已經(jīng)提交的版本可見自己事務(wù)修改的版本可見其他未提交事務(wù)的版本不可見。這樣一來只要隔離級(jí)別是“讀已提交及以上”快照讀在同一個(gè)事務(wù)里保持快照一致就可以自然規(guī)避不可重復(fù)讀的大部分情況。MVCC 最大的價(jià)值是讓讀和寫不互相阻塞。傳統(tǒng)數(shù)據(jù)庫(kù)靠行鎖讀要等寫釋放鎖寫也要等讀完成有了 MVCC普通讀直接去讀歷史版本完全不用等待寫事務(wù)提交。3.3 當(dāng)前讀和快照讀別混為一談寫操作和部分讀操作需要拿到最新數(shù)據(jù)所以不能走快照得走當(dāng)前讀。以下 SQL 都屬于當(dāng)前讀SELECT ... FOR UPDATE; SELECT ... FOR SHARE; -- 或 LOCK IN SHARE MODE UPDATE table SET ... ; DELETE FROM table WHERE ...; INSERT INTO table VALUES (...);當(dāng)前讀讀的是最新已提交版本并且會(huì)對(duì)命中的記錄加鎖。當(dāng)前讀也好快照讀也好它們各自的隔離表現(xiàn)不完全一致這也解釋了后面要說的一個(gè)現(xiàn)象可重復(fù)讀下快照讀通常不會(huì)遇到幻讀但當(dāng)前讀配合不當(dāng)時(shí)仍然可能遇到。我舉個(gè)例子你就能記住兩者的差別你在 REPEATABLE READ 下開一個(gè)事務(wù)第一條 SELECT 走快照讀到了一個(gè)舊一致快照緊接著另一個(gè)事務(wù)插入新記錄并提交此時(shí)你再用普通 SELECT 查依然看不到那條新記錄。但如果你換成SELECT ... FOR UPDATE去查當(dāng)前讀看到最新數(shù)據(jù)可能就把新記錄查出來了。兩種讀的結(jié)果不一致這是排查問題時(shí)要特別留意的點(diǎn)。4. 四種隔離級(jí)別逐個(gè)拆解——該配哪個(gè)差異在哪4.1 讀未提交READ UNCOMMITTED基本只存在于教科書讀未提交允許一個(gè)事務(wù)讀取另一個(gè)事務(wù)尚未提交的修改臟讀這個(gè)現(xiàn)象在這里被合法放行。這個(gè)級(jí)別大部分?jǐn)?shù)據(jù)庫(kù)產(chǎn)品都不建議日常使用因?yàn)榧词共豢紤]臟讀它的并發(fā)控制也幾乎形同虛設(shè)。什么場(chǎng)景適合它呢我確實(shí)見過有人為了追求極致讀取性能用它對(duì)某些非敏感的統(tǒng)計(jì)報(bào)表跑批量查詢數(shù)據(jù)有點(diǎn)臟也能接受排名少幾號(hào)無傷大雅。但從工程穩(wěn)妥角度講我不推薦線上關(guān)鍵鏈路用這個(gè)隔離級(jí)別臟讀一旦蔓延到下游很難查清楚數(shù)據(jù)污染是從哪個(gè)環(huán)節(jié)開始的。4.2 讀已提交READ COMMITTED大多數(shù)業(yè)務(wù)的安全線讀已提交的含義很直接一個(gè)事務(wù)只能讀到其他事務(wù)已經(jīng)提交的數(shù)據(jù)未提交數(shù)據(jù)讀不到臟讀被解決但不可重復(fù)讀仍然存在。它最典型的使用者是 Oracle 和 PostgreSQL 的默認(rèn)級(jí)別MySQL 里也有不少團(tuán)隊(duì)為了方便 binlog 和主從復(fù)制專門把默認(rèn)級(jí)別切到它。它的一個(gè)細(xì)節(jié)是每次 SELECT 都會(huì)獲取新的快照所以在同一事務(wù)內(nèi)的兩次 SELECT 結(jié)果可能不一致。如果你的業(yè)務(wù)對(duì)“事務(wù)內(nèi)多次讀取一致”沒有嚴(yán)格需求讀已提交是性能和正確性之間比較均衡的檔位。但是有一點(diǎn)必須提醒MySQL 在 READ COMMITTED 下UPDATE 和 DELETE 這類當(dāng)前讀的加鎖范圍限制在記錄鎖不會(huì)再加間隙鎖。所以如果你的業(yè)務(wù)有“防止某個(gè)區(qū)間插入新訂單”的需求在這個(gè)級(jí)別下就要用別的手段比如唯一索引、應(yīng)用層狀態(tài)判斷必要時(shí)顯式SELECT ... FOR UPDATE但也要清楚它鎖不住間隙。4.3 可重復(fù)讀REPEATABLE READMySQL 的默認(rèn)選擇也是默認(rèn)自信的來源可重復(fù)讀指同一個(gè)事務(wù)里普通 SELECT 多次執(zhí)行結(jié)果保持一致。它通過 MVCC 的快照復(fù)用 當(dāng)前讀時(shí)的臨鍵鎖擋住了臟讀、不可重復(fù)讀并對(duì)幻讀做了相當(dāng)程度的攔截。這也是 MySQL 官方默認(rèn)配置tx_isolation默認(rèn)值就是 REPEATABLE READ。很多人疑惑為什么 MySQL 不像 Oracle 一樣把默認(rèn)級(jí)別定為 READ COMMITTED一個(gè)很重要原因是 MySQL 的 binlog 在 statement 格式下主從復(fù)制要求所有語(yǔ)句在主庫(kù)執(zhí)行時(shí)的行為必須和從庫(kù)回放時(shí)一致。REPEATABLE READ 配合臨鍵鎖能讓事務(wù)執(zhí)行的所有 SQL 在一個(gè)一致的視圖下跑從庫(kù)重放時(shí)也穩(wěn)定。一旦改成 READ COMMITTED某些帶排序、遍歷的語(yǔ)句生成的 binlog 在從庫(kù)上可能出現(xiàn)重復(fù)執(zhí)行或結(jié)果不一致的情況。這也是為什么網(wǎng)上老有“DDL 大事務(wù) 低檔默認(rèn)隔離級(jí)別”的討論?？芍貜?fù)讀也并非沒有代價(jià)。它的 MVCC 版本鏈保留時(shí)間更久undo log 膨脹壓力更大事務(wù)遲遲不提交歷史版本不能清理最后可能造成undo log瘋狂成長(zhǎng)甚至觸發(fā)線上磁盤告警。后面故障案例里我會(huì)再提這個(gè)問題。4.4 串行化SERIALIZABLE最安全的“全排隊(duì)”串行化是隔離級(jí)別的天花板事務(wù)基本按順序執(zhí)行讀寫之間都可能互相阻塞。實(shí)現(xiàn)方式就是在普通 SELECT 上也加共享鎖讀鎖寫入需要拿到排他鎖這樣并發(fā)度被壓到最低性能也是最差的。什么時(shí)候才值得用我見過兩種典型一種是某些對(duì)一致性要求極高的配置接口比如發(fā)布上線時(shí)要把一批配置原子替換期間不允許任何讀操作看到半新半舊的數(shù)據(jù)另一種是小流量但強(qiáng)一致的系統(tǒng)比如內(nèi)部管理后臺(tái)的極少數(shù)核心頁(yè)面。對(duì)于一般高并發(fā)業(yè)務(wù)串行化基本是把可用性往死里壓不建議亂上。4.5 配置與驗(yàn)證SQL 走一遍就會(huì)了查看和修改事務(wù)隔離級(jí)別的常用命令如下-- 查看當(dāng)前會(huì)話和全局的隔離級(jí)別 SELECT transaction_isolation; SELECT global.transaction_isolation; -- 設(shè)置當(dāng)前會(huì)話隔離級(jí)別 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 設(shè)置全局默認(rèn)重啟失效需要寫配置文件 SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;如果要在配置文件中持久化在 MySQL 5.7 及以上一般這么寫[mysqld] transaction-isolation READ-COMMITTED改完記得驗(yàn)證啟動(dòng)參數(shù)生效別只改配置文件忘記重啟。有一個(gè)坑我多次遇到連接池里的舊連接不會(huì)拿到新隔離級(jí)別你用SET GLOBAL改了之后很多已存在的連接依然沿用舊配置。要確保所有連接都生效最好重啟應(yīng)用連接池或者逐個(gè)SET SESSION。5. 隔離級(jí)別怎么選——業(yè)務(wù)特質(zhì)決定配置別照抄別人5.1 先看你的業(yè)務(wù)是讀多寫多、重一致還是重性能隔離級(jí)別的選擇沒有絕對(duì)最優(yōu)只有匹配業(yè)務(wù)。我總結(jié)了一套實(shí)際項(xiàng)目里常用的判斷邏輯業(yè)務(wù)核心是訂單、賬單、庫(kù)存、余額這類強(qiáng)一致場(chǎng)景優(yōu)先考慮 REPEATABLE READ它能讓同一個(gè)事務(wù)內(nèi)的多次查詢保持視圖一致相對(duì)不容易出陰間錯(cuò)誤。業(yè)務(wù)是內(nèi)容社區(qū)、日志統(tǒng)計(jì)、報(bào)表分析對(duì)“同一事務(wù)內(nèi)重復(fù)讀一致性”沒那么敏感又希望更低的鎖競(jìng)爭(zhēng)和更小的間隙鎖范圍直接用 READ COMMITTED 往往更舒服。至于 READ UNCOMMITTED除非你完全接受臟讀否則別碰SERIALIZABLE 只在極少數(shù)低并發(fā)強(qiáng)一致窗口用一般不建議作為全局默認(rèn)。這里要插一句MySQL 官方默認(rèn) REPEATABLE READ 不是說所有項(xiàng)目都必須用它。很多互聯(lián)網(wǎng)公司為了減少間隙鎖帶來的死鎖喜歡把默認(rèn)切到 READ COMMITTED。尤其是 binlog 格式為 ROW 的時(shí)候statement 復(fù)制兼容性問題基本消除READ COMMITTED 的收益會(huì)更明顯。5.2 常見讀寫場(chǎng)景下的推薦配置我平時(shí)給團(tuán)隊(duì)定的默認(rèn)調(diào)法是沒有特殊要求數(shù)據(jù)庫(kù)內(nèi)統(tǒng)一 REPEATABLE READ單個(gè)事務(wù)保持短小快速對(duì)超大報(bào)表查詢單獨(dú)開只讀事務(wù)并把隔離級(jí)別降到 READ COMMITTED。短事務(wù)在 REPEATABLE READ 下壓力不大還天然規(guī)避了不可重復(fù)讀長(zhǎng)事務(wù)則容易膨脹 undo必須單獨(dú)設(shè)計(jì)。寫操作競(jìng)爭(zhēng)激烈的熱點(diǎn)行比如秒殺庫(kù)存、點(diǎn)贊計(jì)數(shù)字段再高的隔離級(jí)別也救不了“先讀后寫”的并發(fā)覆蓋問題。這種場(chǎng)景需要做兩種補(bǔ)充一是原子 SQL 操作比如UPDATE stock SET count count - 1 WHERE count 0二是樂觀鎖版本號(hào)在 UPDATE 的 WHERE 條件里帶上version 目標(biāo)版本號(hào)更新成功說明版本沒變失敗則需要重試。隔離級(jí)別管的是“讀”的一致性管不住業(yè)務(wù)自己算出來的臟結(jié)果這個(gè)界限要分清。5.3 不會(huì)選的時(shí)候會(huì)出現(xiàn)的三個(gè)典型現(xiàn)象第一個(gè)現(xiàn)象是“死鎖變多”。全局改成 READ COMMITTED 后間隙鎖少了按理說死鎖概率應(yīng)該降低但如果你的 SQL 都在跑二級(jí)索引范圍掃描記錄鎖的鎖順序不一致一樣會(huì)死鎖。排查死鎖時(shí)先SHOW ENGINE INNODB STATUS把鎖等待信息撈出來看看再?zèng)Q定是改索引順序還是調(diào)整隔離級(jí)別。第二個(gè)現(xiàn)象是“主從數(shù)據(jù)不一致自查”。如果你的 binlog 用的是 STATEMENT 格式底層隔離級(jí)別又是 READ COMMITTED某些 UPDATE 語(yǔ)句在不同時(shí)間點(diǎn)取當(dāng)前讀的結(jié)果可能不同從庫(kù)重放就容易出現(xiàn)偏差。驗(yàn)證不夠充分的話建議直接切 ROW 格式數(shù)據(jù)一致性檢測(cè)也省心。第三個(gè)現(xiàn)象是“長(zhǎng)事務(wù)拖垮回滾段”。不管什么隔離級(jí)別只要事務(wù)長(zhǎng)時(shí)間不提交歷史版本就清不掉。常見于代碼里事務(wù)內(nèi)嵌入外部 HTTP 請(qǐng)求或者晚上跑批任務(wù)開著事務(wù)過夜。治理手段很簡(jiǎn)單事務(wù)里只做數(shù)據(jù)庫(kù)操作網(wǎng)絡(luò)調(diào)用全部移出事務(wù)實(shí)在要跑批就給每幾千行一個(gè)大事務(wù)做一次提交切分。6. 一次真實(shí)故障復(fù)盤——隔離級(jí)別相關(guān)問題的定位與修復(fù)6.1 故障現(xiàn)象一個(gè)訂單狀態(tài)流轉(zhuǎn)的“幽靈數(shù)據(jù)”之前幫某個(gè)電商項(xiàng)目排查過一個(gè)很有意思的問題。現(xiàn)象是運(yùn)營(yíng)后臺(tái)里一個(gè)訂單的狀態(tài)在待支付和已支付之間反復(fù)跳變但數(shù)據(jù)庫(kù)里查到的字段值卻是穩(wěn)定的。后來發(fā)現(xiàn)是事務(wù)隔離級(jí)別和當(dāng)前讀的混用問題。業(yè)務(wù)代碼邏輯大概是這樣的用戶在支付回調(diào)里起一個(gè)事務(wù)第一步用普通 SELECT 查訂單狀態(tài)發(fā)現(xiàn)是“待支付”第二步執(zhí)行 UPDATE 把它改成“已支付”第三步提交。同一個(gè)事務(wù)里理論上可重復(fù)讀會(huì)讓我們看到一致快照但 UPDATE 本身是當(dāng)前讀它讀到的是已經(jīng)提交的最新數(shù)據(jù)。如果此刻運(yùn)營(yíng)后臺(tái)恰好也改了這條訂單就可能出現(xiàn) UPDATE 覆蓋運(yùn)營(yíng)修改的情況——看起來“狀態(tài)跳變”其實(shí)是兩個(gè)事務(wù)互相覆蓋。6.2 我當(dāng)時(shí)排查的思路與命令排查第一步先確認(rèn)隔離級(jí)別SELECT transaction_isolation; -- 結(jié)果一般是 REPEATABLE READ第二步是把疑似熱點(diǎn)代碼的 SQL 抓出來借助performance_schema或者慢查詢?nèi)罩究从袥]有事務(wù)重疊時(shí)間窗。我直接看了相關(guān)時(shí)間段內(nèi)兩個(gè)連接的鎖等待和事務(wù)狀態(tài)SELECT * FROM information_schema.innodb_trx WHERE trx_started ...;當(dāng)時(shí)兩個(gè)事務(wù)確實(shí)同時(shí)存在一個(gè)跑支付回調(diào)的 UPDATE一個(gè)跑運(yùn)營(yíng)后臺(tái)的狀態(tài)修改。因?yàn)樗鼈兺瑫r(shí)命中同一條記錄記錄鎖互相等待于是出現(xiàn)了看似是狀態(tài)回跳、其實(shí)是鎖競(jìng)爭(zhēng)后的結(jié)果覆蓋。第三步是檢查是否使用了顯式鎖。這種先讀后寫的關(guān)鍵路徑不能依賴隱式行鎖的默認(rèn)行為應(yīng)該用SELECT ... FOR UPDATE把訂單行鎖住再做業(yè)務(wù)判斷和 UPDATE。這樣第二個(gè)事務(wù)必須等第一個(gè)提交后才能讀最新狀態(tài)不會(huì)讀到舊值再覆蓋。6.3 最終的修復(fù)方案與經(jīng)驗(yàn)沉淀修復(fù)時(shí)候我給出的方案是支付回調(diào)里把先讀后寫統(tǒng)一改成“當(dāng)前讀 排他鎖”具體 SQL 如下START TRANSACTION; SELECT * FROM order WHERE id 1001 FOR UPDATE; -- 業(yè)務(wù)校驗(yàn)狀態(tài)是否為待支付、金額是否一致、是否已處理 UPDATE order SET status paid WHERE id 1001; COMMIT;這樣事務(wù)里讀取就鎖住了這條記錄其他事務(wù)的修改必須排隊(duì)等待隔離級(jí)別即便保持 REPEATABLE READ 也沒問題。另外運(yùn)營(yíng)后臺(tái)的讀操作如果只是展示走快照讀即可不會(huì)阻塞但運(yùn)營(yíng)后臺(tái)的批量改狀態(tài)操作也要做成帶狀態(tài)約束的原子 UPDATE比如UPDATE order SET status 待發(fā)貨 WHERE id ... AND status已支付防止把已經(jīng)進(jìn)入新狀態(tài)的訂單覆蓋回去。后來我還順手做了一輪線上巡檢把所有事務(wù)里夾雜外部 HTTP 調(diào)用的代碼全部揪出來改掉并把長(zhǎng)事務(wù)告警閾值從 10 分鐘改成 5 分鐘。這套操作走了下來線上相關(guān)故障再?zèng)]出現(xiàn)過第二次。因?yàn)橐姸嗔诉@種和隔離級(jí)別強(qiáng)相關(guān)、但根因卻在代碼加鎖姿勢(shì)上的問題我現(xiàn)在做技術(shù)方案評(píng)審時(shí)有個(gè)習(xí)慣先問清這個(gè)寫事務(wù)里是否會(huì)“先讀再寫”再問這個(gè)讀是否需要加鎖而不是直接丟一句“數(shù)據(jù)庫(kù)默認(rèn)是可重復(fù)讀應(yīng)該沒問題”。隔離級(jí)別能解決一部分問題但不是所有并發(fā)正確性的銀彈。你手里真正要握穩(wěn)的是理解當(dāng)前讀、快照讀、鎖定范圍三者之間的關(guān)系然后在關(guān)鍵業(yè)務(wù)路徑上把鎖加到位事務(wù)盡量縮短別把長(zhǎng)期運(yùn)行的大事務(wù)丟給數(shù)據(jù)庫(kù)硬扛。