提到事務(wù)，你肯定不陌生，和數(shù)據(jù)庫(kù)打交道的時(shí)候，我們總是會(huì)用到事務(wù)。最經(jīng)典的例子就是轉(zhuǎn)賬，你要給朋友小王轉(zhuǎn)100塊錢(qián)，而此時(shí)你的銀行卡只有100塊錢(qián)。

轉(zhuǎn)賬過(guò)程具體到程序里會(huì)有一系列的操作，比如查詢(xún)余額、做加減法、更新余額等，這些操作必須保證是一體的，不然等程序查完之后，還沒(méi)做減法之前，你這100塊錢(qián)，完全可以借著這個(gè)時(shí)間差再查一次，然后再給另外一個(gè)朋友轉(zhuǎn)賬，如果銀行這么整，不就亂了么？這時(shí)就要用到“事務(wù)”這個(gè)概念了。

簡(jiǎn)單來(lái)說(shuō)，事務(wù)就是要保證一組數(shù)據(jù)庫(kù)操作，要么全部成功，要么全部失敗。在MySQL中，事務(wù)支持是在引擎層實(shí)現(xiàn)的。你現(xiàn)在知道，MySQL是一個(gè)支持多引擎的系統(tǒng)，但并不是所有的引擎都支持事務(wù)。比如MySQL原生的MyISAM引擎就不支持事務(wù)，這也是MyISAM被InnoDB取代的重要原因之一。

今天的文章里，我將會(huì)以InnoDB為例，剖析MySQL在事務(wù)支持方面的特定實(shí)現(xiàn)，并基于原理給出相應(yīng)的實(shí)踐建議，希望這些案例能加深你對(duì)MySQL事務(wù)原理的理解。

隔離性與隔離級(jí)別

提到事務(wù)，你肯定會(huì)想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔離性、持久性），今天我們就來(lái)說(shuō)說(shuō)其中I，也就是“隔離性”。

當(dāng)數(shù)據(jù)庫(kù)上有多個(gè)事務(wù)同時(shí)執(zhí)行的時(shí)候，就可能出現(xiàn)臟讀（dirty read）、不可重復(fù)讀（non-repeatable read）、幻讀（phantom read）的問(wèn)題，為了解決這些問(wèn)題，就有了“隔離級(jí)別”的概念。

在談隔離級(jí)別之前，你首先要知道，你隔離得越嚴(yán)實(shí)，效率就會(huì)越低。因此很多時(shí)候，我們都要在二者之間尋找一個(gè)平衡點(diǎn)。SQL標(biāo)準(zhǔn)的事務(wù)隔離級(jí)別包括：讀未提交（read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（serializable ）。下面我逐一為你解釋：

• 讀未提交是指，一個(gè)事務(wù)還沒(méi)提交時(shí)，它做的變更就能被別的事務(wù)看到。
• 讀提交是指，一個(gè)事務(wù)提交之后，它做的變更才會(huì)被其他事務(wù)看到。
• 可重復(fù)讀是指，一個(gè)事務(wù)執(zhí)行過(guò)程中看到的數(shù)據(jù)，總是跟這個(gè)事務(wù)在啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的。當(dāng)然在可重復(fù)讀隔離級(jí)別下，未提交變更對(duì)其他事務(wù)也是不可見(jiàn)的。
• 串行化，顧名思義是對(duì)于同一行記錄，“寫(xiě)”會(huì)加“寫(xiě)鎖”，“讀”會(huì)加“讀鎖”。當(dāng)出現(xiàn)讀寫(xiě)鎖沖突的時(shí)候，后訪(fǎng)問(wèn)的事務(wù)必須等前一個(gè)事務(wù)執(zhí)行完成，才能繼續(xù)執(zhí)行。

其中“讀提交”和“可重復(fù)讀”比較難理解，所以我用一個(gè)例子說(shuō)明這幾種隔離級(jí)別。假設(shè)數(shù)據(jù)表T中只有一列，其中一行的值為1，下面是按照時(shí)間順序執(zhí)行兩個(gè)事務(wù)的行為。

mysql> create table T(c int) engine=InnoDB; insert into T(c) values(1);

我們來(lái)看看在不同的隔離級(jí)別下，事務(wù)A會(huì)有哪些不同的返回結(jié)果，也就是圖里面V1、V2、V3的返回值分別是什么。

• 若隔離級(jí)別是“讀未提交”， 則V1的值就是2。這時(shí)候事務(wù)B雖然還沒(méi)有提交，但是結(jié)果已經(jīng)被A看到了。因此，V2、V3也都是2。
• 若隔離級(jí)別是“讀提交”，則V1是1，V2的值是2。事務(wù)B的更新在提交后才能被A看到。所以， V3的值也是2。
• 若隔離級(jí)別是“可重復(fù)讀”，則V1、V2是1，V3是2。之所以V2還是1，遵循的就是這個(gè)要求：事務(wù)在執(zhí)行期間看到的數(shù)據(jù)前后必須是一致的。
• 若隔離級(jí)別是“串行化”，則在事務(wù)B執(zhí)行“將1改成2”的時(shí)候，會(huì)被鎖住。直到事務(wù)A提交后，事務(wù)B才可以繼續(xù)執(zhí)行。所以從A的角度看， V1、V2值是1，V3的值是2。

在實(shí)現(xiàn)上，數(shù)據(jù)庫(kù)里面會(huì)創(chuàng)建一個(gè)視圖，訪(fǎng)問(wèn)的時(shí)候以視圖的邏輯結(jié)果為準(zhǔn)。在“可重復(fù)讀”隔離級(jí)別下，這個(gè)視圖是在事務(wù)啟動(dòng)時(shí)創(chuàng)建的，整個(gè)事務(wù)存在期間都用這個(gè)視圖。在“讀提交”隔離級(jí)別下，這個(gè)視圖是在每個(gè)SQL語(yǔ)句開(kāi)始執(zhí)行的時(shí)候創(chuàng)建的。這里需要注意的是，“讀未提交”隔離級(jí)別下直接返回記錄上的最新值，沒(méi)有視圖概念；而“串行化”隔離級(jí)別下直接用加鎖的方式來(lái)避免并行訪(fǎng)問(wèn)。

我們可以看到在不同的隔離級(jí)別下，數(shù)據(jù)庫(kù)行為是有所不同的。Oracle數(shù)據(jù)庫(kù)的默認(rèn)隔離級(jí)別其實(shí)就是“讀提交”，因此對(duì)于一些從Oracle遷移到MySQL的應(yīng)用，為保證數(shù)據(jù)庫(kù)隔離級(jí)別的一致，你一定要記得將MySQL的隔離級(jí)別設(shè)置為“讀提交”。

配置的方式是，將啟動(dòng)參數(shù)transaction-isolation的值設(shè)置成READ-COMMITTED。你可以用show variables來(lái)查看當(dāng)前的值。

mysql> show variables like 'transaction_isolation';+-----------------------+----------------+| Variable_name | Value |+-----------------------+----------------+| transaction_isolation | READ-COMMITTED |+-----------------------+----------------+

總結(jié)來(lái)說(shuō)，存在即合理，哪個(gè)隔離級(jí)別都有它自己的使用場(chǎng)景，你要根據(jù)自己的業(yè)務(wù)情況來(lái)定。我想你可能會(huì)問(wèn)那什么時(shí)候需要“可重復(fù)讀”的場(chǎng)景呢？我們來(lái)看一個(gè)數(shù)據(jù)校對(duì)邏輯的案例。

假設(shè)你在管理一個(gè)個(gè)人銀行賬戶(hù)表。一個(gè)表存了每個(gè)月月底的余額，一個(gè)表存了賬單明細(xì)。這時(shí)候你要做數(shù)據(jù)校對(duì)，也就是判斷上個(gè)月的余額和當(dāng)前余額的差額，是否與本月的賬單明細(xì)一致。你一定希望在校對(duì)過(guò)程中，即使有用戶(hù)發(fā)生了一筆新的交易，也不影響你的校對(duì)結(jié)果。

這時(shí)候使用“可重復(fù)讀”隔離級(jí)別就很方便。事務(wù)啟動(dòng)時(shí)的視圖可以認(rèn)為是靜態(tài)的，不受其他事務(wù)更新的影響。

事務(wù)隔離的實(shí)現(xiàn)

理解了事務(wù)的隔離級(jí)別，我們?cè)賮?lái)看看事務(wù)隔離具體是怎么實(shí)現(xiàn)的。這里我們展開(kāi)說(shuō)明“可重復(fù)讀”。

在MySQL中，實(shí)際上每條記錄在更新的時(shí)候都會(huì)同時(shí)記錄一條回滾操作。記錄上的最新值，通過(guò)回滾操作，都可以得到前一個(gè)狀態(tài)的值。

假設(shè)一個(gè)值從1被按順序改成了2、3、4，在回滾日志里面就會(huì)有類(lèi)似下面的記錄。

當(dāng)前值是4，但是在查詢(xún)這條記錄的時(shí)候，不同時(shí)刻啟動(dòng)的事務(wù)會(huì)有不同的read-view。如圖中看到的，在視圖A、B、C里面，這一個(gè)記錄的值分別是1、2、4，同一條記錄在系統(tǒng)中可以存在多個(gè)版本，就是數(shù)據(jù)庫(kù)的多版本并發(fā)控制（MVCC）。對(duì)于read-view A，要得到1，就必須將當(dāng)前值依次執(zhí)行圖中所有的回滾操作得到。

同時(shí)你會(huì)發(fā)現(xiàn)，即使現(xiàn)在有另外一個(gè)事務(wù)正在將4改成5，這個(gè)事務(wù)跟read-view A、B、C對(duì)應(yīng)的事務(wù)是不會(huì)沖突的。

你一定會(huì)問(wèn)，回滾日志總不能一直保留吧，什么時(shí)候刪除呢？答案是，在不需要的時(shí)候才刪除。也就是說(shuō)，系統(tǒng)會(huì)判斷，當(dāng)沒(méi)有事務(wù)再需要用到這些回滾日志時(shí)，回滾日志會(huì)被刪除。

什么時(shí)候才不需要了呢？就是當(dāng)系統(tǒng)里沒(méi)有比這個(gè)回滾日志更早的read-view的時(shí)候。

基于上面的說(shuō)明，我們來(lái)討論一下為什么建議你盡量不要使用長(zhǎng)事務(wù)。

長(zhǎng)事務(wù)意味著系統(tǒng)里面會(huì)存在很老的事務(wù)視圖。由于這些事務(wù)隨時(shí)可能訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)里面的任何數(shù)據(jù)，所以這個(gè)事務(wù)提交之前，數(shù)據(jù)庫(kù)里面它可能用到的回滾記錄都必須保留，這就會(huì)導(dǎo)致大量占用存儲(chǔ)空間。

在MySQL 5.5及以前的版本，回滾日志是跟數(shù)據(jù)字典一起放在ibdata文件里的，即使長(zhǎng)事務(wù)最終提交，回滾段被清理，文件也不會(huì)變小。我見(jiàn)過(guò)數(shù)據(jù)只有20GB，而回滾段有200GB的庫(kù)。最終只好為了清理回滾段，重建整個(gè)庫(kù)。

除了對(duì)回滾段的影響，長(zhǎng)事務(wù)還占用鎖資源，也可能拖垮整個(gè)庫(kù)，這個(gè)我們會(huì)在后面講鎖的時(shí)候展開(kāi)。

事務(wù)的啟動(dòng)方式

如前面所述，長(zhǎng)事務(wù)有這些潛在風(fēng)險(xiǎn)，我當(dāng)然是建議你盡量避免。其實(shí)很多時(shí)候業(yè)務(wù)開(kāi)發(fā)同學(xué)并不是有意使用長(zhǎng)事務(wù)，通常是由于誤用所致。MySQL的事務(wù)啟動(dòng)方式有以下幾種：

顯式啟動(dòng)事務(wù)語(yǔ)句， begin 或 start transaction。配套的提交語(yǔ)句是commit，回滾語(yǔ)句是rollback。

set autocommit=0，這個(gè)命令會(huì)將這個(gè)線(xiàn)程的自動(dòng)提交關(guān)掉。意味著如果你只執(zhí)行一個(gè)select語(yǔ)句，這個(gè)事務(wù)就啟動(dòng)了，而且并不會(huì)自動(dòng)提交。這個(gè)事務(wù)持續(xù)存在直到你主動(dòng)執(zhí)行commit 或 rollback 語(yǔ)句，或者斷開(kāi)連接。

有些客戶(hù)端連接框架會(huì)默認(rèn)連接成功后先執(zhí)行一個(gè)set autocommit=0的命令。這就導(dǎo)致接下來(lái)的查詢(xún)都在事務(wù)中，如果是長(zhǎng)連接，就導(dǎo)致了意外的長(zhǎng)事務(wù)。

因此，我會(huì)建議你總是使用set autocommit=1, 通過(guò)顯式語(yǔ)句的方式來(lái)啟動(dòng)事務(wù)。

但是有的開(kāi)發(fā)同學(xué)會(huì)糾結(jié)“多一次交互”的問(wèn)題。對(duì)于一個(gè)需要頻繁使用事務(wù)的業(yè)務(wù)，第二種方式每個(gè)事務(wù)在開(kāi)始時(shí)都不需要主動(dòng)執(zhí)行一次 “begin”，減少了語(yǔ)句的交互次數(shù)。如果你也有這個(gè)顧慮，我建議你使用commit work and chain語(yǔ)法。

在autocommit為1的情況下，用begin顯式啟動(dòng)的事務(wù)，如果執(zhí)行commit則提交事務(wù)。如果執(zhí)行 commit work and chain，則是提交事務(wù)并自動(dòng)啟動(dòng)下一個(gè)事務(wù)，這樣也省去了再次執(zhí)行begin語(yǔ)句的開(kāi)銷(xiāo)。同時(shí)帶來(lái)的好處是從程序開(kāi)發(fā)的角度明確地知道每個(gè)語(yǔ)句是否處于事務(wù)中。

你可以在information_schema庫(kù)的innodb_trx這個(gè)表中查詢(xún)長(zhǎng)事務(wù)，比如下面這個(gè)語(yǔ)句，用于查找持續(xù)時(shí)間超過(guò)60s的事務(wù)。

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

小結(jié)

這篇文章里面，我介紹了MySQL的事務(wù)隔離級(jí)別的現(xiàn)象和實(shí)現(xiàn)，根據(jù)實(shí)現(xiàn)原理分析了長(zhǎng)事務(wù)存在的風(fēng)險(xiǎn)，以及如何用正確的方式避免長(zhǎng)事務(wù)。希望我舉的例子能夠幫助你理解事務(wù)，并更好地使用MySQL的事務(wù)特性。

我給你留一個(gè)問(wèn)題吧。你現(xiàn)在知道了系統(tǒng)里面應(yīng)該避免長(zhǎng)事務(wù)，如果你是業(yè)務(wù)開(kāi)發(fā)負(fù)責(zé)人同時(shí)也是數(shù)據(jù)庫(kù)負(fù)責(zé)人，你會(huì)有什么方案來(lái)避免出現(xiàn)或者處理這種情況呢？

你可以把你的思考和觀點(diǎn)寫(xiě)在留言區(qū)里，我會(huì)在下一篇文章的末尾和你討論這個(gè)問(wèn)題。感謝你的收聽(tīng)，也歡迎你把這篇文章分享給更多的朋友一起閱讀。

上期問(wèn)題時(shí)間

在上期文章的最后，我給你留下的問(wèn)題是一天一備跟一周一備的對(duì)比。

好處是“最長(zhǎng)恢復(fù)時(shí)間”更短。

在一天一備的模式里，最壞情況下需要應(yīng)用一天的binlog。比如，你每天0點(diǎn)做一次全量備份，而要恢復(fù)出一個(gè)到昨天晚上23點(diǎn)的備份。

一周一備最壞情況就要應(yīng)用一周的binlog了。

系統(tǒng)的對(duì)應(yīng)指標(biāo)就是 @尼古拉斯·趙四 @慕塔 提到的RTO（恢復(fù)目標(biāo)時(shí)間）。

當(dāng)然這個(gè)是有成本的，因?yàn)楦l繁全量備份需要消耗更多存儲(chǔ)空間，所以這個(gè)RTO是成本換來(lái)的，就需要你根據(jù)業(yè)務(wù)重要新來(lái)評(píng)估了。

轉(zhuǎn)載于:https://www.cnblogs.com/a-phper/p/10007202.html

總結(jié)

以上是生活随笔為你收集整理的03 | 事务隔离：为什么你改了我还看不见？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。