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