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

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

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

今天的文章里，將會以 InnoDB 為例，剖析 MySQL 在事務(wù)支持方面的特定實(shí)現(xiàn)，并基于原理給出相應(yīng)的實(shí)踐建議.

隔離性與隔離級別

提到事務(wù),你肯定會想到ACID(Atomicity,Consistency,Isolation,Durability,即原子性,一致性,隔離性,持久性),今天我們就來說說其中I,也就是隔離性.

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

在談隔離級別之前,你首先要知道,你隔離得越嚴(yán)實(shí),效率就會越低,因此很多時候,我們都要在兩者之間尋找一個平衡點(diǎn).SQL標(biāo)準(zhǔn)的事務(wù)隔離級別包括:讀未提交(read uncommitted).讀提交(read commited),可重復(fù)讀(repeatable read)和串行化(serializable) .

讀未提交是指,一個事務(wù)還沒提交時,它做的變更就能被別的事務(wù)看到.

讀提交是指,一個事務(wù)提交之后,它做的變更才會被其他事務(wù)看到.

可重復(fù)讀是指,一個和事務(wù)執(zhí)行過程中看到的數(shù)據(jù),總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)時一致的.當(dāng)然在可重復(fù)讀隔離級別下,未提交變更對其他事務(wù)也是不可見的.

串行化,顧名思義時對于同一行記錄,"寫"會加"寫鎖","讀"會加"讀鎖".當(dāng)出現(xiàn)讀寫鎖沖突的時候,后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成,才能繼續(xù)執(zhí)行.

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

create table T(c int) engine = innoDB;

insert into T(c) values(1);

我們來看看在不同的隔離級別下,事務(wù)A會有哪些不同的返回結(jié)果,也就是圖里面V1,V2,V3的返回值分別是什么.

若隔離級別的"讀未提交",則V1的值就是2.這時候事務(wù)B雖然還沒有提交但是結(jié)果已經(jīng)被A看到了,因此,V2.V3也都是2.

若隔離級別是"讀提交",則V1是1,V2的值是2,事務(wù)B的更新在提交后才能被A看到,所以,V3的值也是2.

若隔離級別是"可重復(fù)讀",則V1,V2是1,V3是2.之所以V2還是1,遵循的就是這個要求:事務(wù)在執(zhí)行期間看到的數(shù)據(jù)前后必須是一致的.

若隔離級別是"串行化",則事務(wù)B志執(zhí)行"將1改成2"的時候,會被鎖住.知道事務(wù)A提交后,事務(wù)B才可以繼續(xù)執(zhí)行,所以從A的角度看,V1,V2值是1,V3的值是2.

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

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

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

show variables like 'transaction_isolation';

總結(jié)來說,存在即合理,哪個隔離級別都有它自己的使用場景,你要根據(jù)自己的業(yè)務(wù)情況來定.我想你可能會問哪什么時候需要"可重復(fù)讀"的場景呢?我們來看一個數(shù)據(jù)校對邏輯的案例.

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

這時候使用"可重復(fù)讀"隔離級別就很方便.事務(wù)啟動時的視圖可以認(rèn)為時靜態(tài)的,不受其他事務(wù)更新的影響.

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

理解了事務(wù)的隔離級別,我們再來看看事務(wù)隔離具體時怎么實(shí)現(xiàn)的.這里我們展開說明"可重復(fù)讀".

在mysql中,實(shí)際上每條記錄都在更新的時候都會同時記錄一條回滾操作.記錄上的最新值,通過回滾操作,都可以得到前一個狀態(tài)的值.

假設(shè)一個值從1被按順序改成了2,3,4,在回滾日志里面就會有類似下面的記錄.

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

同時你會發(fā)現(xiàn),即使現(xiàn)在有另一個事務(wù)正在將4改成5,這個事務(wù)跟read-viewA,B,C對應(yīng)的事務(wù)時不會沖突的.

你一定會問,回滾日志中不能一致保留把,什么時候刪除呢?答案是,在不需要的時候才刪除.也就是說,系統(tǒng)會判斷,當(dāng)沒有事務(wù)在需要用到這些回滾日志時,回滾日志會被刪除.

什么時候才不需要了呢?就是當(dāng)系統(tǒng)里沒有比這個回滾日志更早的read-view的時候.

基于上面的說明,我們來討論一下為什么建議你盡量不要使用長事務(wù).

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

在mysql5.5及以前的版本,回滾日志是跟數(shù)據(jù)字典一起放在ibdata文件里的,即使長事務(wù)最終提交,回滾段被清理,文件也不會變小.我見過數(shù)據(jù)只有20G,而回滾段有200G的庫,最終只好為了清理回滾段,重建整個庫.

除了對回滾段的影響,長事務(wù)還占用鎖資源,也可能拖垮整個庫,這個我們會在后面講鎖的時候展開.

事務(wù)的啟動方式

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

1.顯式啟動事務(wù)語句,begin或start transaction.配套的提交語句是commit,回滾語句是rollback.

2.set autocommit = 0,這個命令會將這個線程的自動提交關(guān)掉.意味著如果你只執(zhí)行一個select語句,這個事務(wù)就啟動了,而且并不會自動提交.這個事務(wù)持續(xù)存在直到你主動執(zhí)行commit或rollback語句,或者斷開連接.

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

因此,我會建議你總是使用set autocommit = 1,通過顯式語句的方式來啟動事務(wù).

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

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

你可以在information_schema庫的innodb_trx這個表中查詢長事務(wù),比如下面這個語句,用于查找持續(xù)時間超過60s的事務(wù).

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