提到事務(wù)共郭,你肯定不陌生祠丝,和數(shù)據(jù)庫(kù)打交道的時(shí)候,我們總是會(huì)用到事務(wù)除嘹。最經(jīng)典的例子就是轉(zhuǎn)賬写半,你要給朋友小王轉(zhuǎn)100塊錢,而此時(shí)你的銀行卡只有100塊錢尉咕。
轉(zhuǎn)賬的過程具體到程序里會(huì)有一系列的操作叠蝇,比如查詢余額、做加減法年缎、更新余額等悔捶,這些操作必須保證是一體的,不然等程序查詢完成之后单芜,還沒做加減法之前蜕该,你這100塊錢,完全可以借著這個(gè)時(shí)間差在查一次洲鸠,然后再給另一個(gè)朋友轉(zhuǎn)賬堂淡,如果銀行這么整,不就亂了嗎扒腕?這時(shí)就要用到"事務(wù)"這個(gè)概念了绢淀。
簡(jiǎn)單來說,事務(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寺谤,即原子性仑鸥、一致性、隔離性变屁、持久性)眼俊,今天我們就來說說其中I,也就是"隔離性"粟关。
當(dāng)數(shù)據(jù)庫(kù)上有多個(gè)事務(wù)同時(shí)執(zhí)行的時(shí)候疮胖,就可能出現(xiàn)臟讀(dirty read)、不可重復(fù)讀(non-repeatable read)誊役、幻讀(phantom read)的問題获列,為了解決這些問題,就有了"隔離級(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ù)還未提交時(shí),它做的變更就能被別的事務(wù)看到秒梳。
- 讀提交是指法绵,一個(gè)事務(wù)提交之后箕速,它做的變更才能被其他事務(wù)看到。
- 可重復(fù)讀是指朋譬,一個(gè)事務(wù)執(zhí)行過程中看到的數(shù)據(jù)盐茎,總是跟這個(gè)事務(wù)在啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的。當(dāng)然在可重復(fù)讀隔離界別下徙赢,未提交變更對(duì)其他事務(wù)也是不可見的字柠。
- 串形化,顧名思義是對(duì)于同一行記錄狡赐,"寫"會(huì)加"寫鎖"窑业,"讀"會(huì)加"讀鎖"。當(dāng)出現(xiàn)讀寫鎖沖突的時(shí)候枕屉,后訪問的事務(wù)必須等前一個(gè)事務(wù)執(zhí)行完成数冬,才能繼續(xù)執(zhí)行。
其中"讀提交"和"可重復(fù)讀"比較難理解搀庶,所以我用一個(gè)例子說明這幾種隔離級(jí)別。假設(shè)數(shù)據(jù)表T中只有一列铜异,其中一行的值為1哥倔,下面是按照時(shí)間順序執(zhí)行兩個(gè)事務(wù)的行為。
mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);
我們來看看不同的隔離級(jí)別下揍庄,事務(wù)A會(huì)有哪些不同的返回結(jié)果咆蒿,也就是圖里面V1、V2蚂子、V3的返回值分別是什么沃测。
- 若隔離級(jí)別是"讀未提交",則V1的值就是2食茎。這時(shí)候事務(wù)B雖然還沒有提交蒂破,但是結(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è)視圖唠倦,訪問的時(shí)候以視圖的邏輯結(jié)果為準(zhǔn)称鳞。在"可重復(fù)讀"隔離級(jí)別下,這個(gè)視圖是在事務(wù)啟動(dòng)時(shí)創(chuàng)建的稠鼻,整個(gè)事務(wù)存在期間都用這個(gè)視圖冈止。在"讀提交"隔離級(jí)別下,這個(gè)視圖是在每個(gè)SQL語(yǔ)句開始執(zhí)行的時(shí)候創(chuàng)建的候齿。這里需要注意的是熙暴,"讀未提交"隔離級(jí)別下直接返回記錄上的最新值,沒有視圖概念慌盯;而"串形化"隔離級(jí)別下直接用加鎖的方式來避免并行訪問周霉。
我們可以看到在不同的隔離級(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來查看當(dāng)前的值厂财。
mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
總結(jié)來說芋簿,存在即合理,哪個(gè)隔離級(jí)別都有它自己的使用場(chǎng)景璃饱,你要根據(jù)自己的業(yè)務(wù)情況來定与斤。我想你可能會(huì)問那什么時(shí)候需要"可重復(fù)讀"的場(chǎng)景呢?我們來看一個(gè)數(shù)據(jù)校對(duì)邏輯的案例。
假設(shè)你在管理一個(gè)個(gè)人銀行賬戶表撩穿。一個(gè)表存了每個(gè)月月底的余額磷支,一個(gè)表存了賬單明細(xì)。這時(shí)候你要做數(shù)據(jù)校對(duì)食寡,也就是判斷上個(gè)月的余額和當(dāng)前余額的差值雾狈,是否與本月賬單明細(xì)一致。你一定希望在校對(duì)過程中抵皱,即使有用戶發(fā)生了一筆新的交易善榛,也不影響你的校對(duì)結(jié)果。
這時(shí)候使用"可重復(fù)讀"隔離級(jí)別就很方便呻畸。事務(wù)啟動(dòng)時(shí)的視圖可以認(rèn)為是靜態(tài)的移盆,不受其他事務(wù)更新的影響。
事務(wù)隔離的實(shí)現(xiàn)
理解了事務(wù)的隔離級(jí)別伤为,我們?cè)賮砜纯词聞?wù)隔離具體是怎么實(shí)現(xiàn)的咒循。這里我們展開說明"可重復(fù)讀"。
在MySQL中绞愚,實(shí)際上每條記錄在更新的時(shí)候都會(huì)同時(shí)記錄一條回滾操作叙甸。記錄上的最新值,通過回滾操作位衩,都可以得到前一個(gè)狀態(tài)的值蚁署。
假設(shè)一個(gè)值從1被按順序改成了2、3蚂四、4,在回滾日志里面就會(huì)有類似下面的記錄哪痰。
當(dāng)前值是4遂赠,但是在查詢這條記錄的時(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ì)問线椰,回滾日志總不能一直保留吧,什么時(shí)候刪除呢尘盼?答案是憨愉,在不需要的時(shí)候才刪除。也就是說悔叽,系統(tǒng)會(huì)判斷莱衩,當(dāng)沒有事務(wù)在需要用到這些回滾日志時(shí),回滾日志會(huì)被刪除娇澎。
什么時(shí)候才不需要了呢笨蚁?就是當(dāng)系統(tǒng)里沒有比這個(gè)回滾日志更早的read-view的時(shí)候。
基于上面的說明趟庄,我們來討論一下為什么建議你盡量不要使用長(zhǎng)事務(wù)括细。
長(zhǎng)事務(wù)意味著系統(tǒng)里面會(huì)存在很老的事務(wù)視圖。由于這些事務(wù)隨時(shí)可能訪問數(shù)據(jù)庫(kù)里面的任何數(shù)據(jù)戚啥,所以在這個(gè)事務(wù)提交之前奋单,數(shù)據(jù)庫(kù)里面它可能用到的回滾記錄都必須保留,這就會(huì)導(dǎo)致大量占用存儲(chǔ)空間猫十。
在MySQL5.5及以前的版本览濒,回滾日志是跟數(shù)據(jù)字典一起放在ibdata文件里的,即使長(zhǎng)事務(wù)最終提交拖云,回滾段被清理贷笛,文件也不會(huì)變小。我見過數(shù)據(jù)只有20GB宙项,而回滾段有200GB的庫(kù)乏苦。最終只好位了清理回滾段,重建整個(gè)庫(kù)尤筐。
除了對(duì)回滾段的影響汇荐,長(zhǎng)事務(wù)還占用鎖資源,也可能拖垮整個(gè)庫(kù)盆繁,這個(gè)我們會(huì)在后面講鎖的時(shí)候展開掀淘。
事務(wù)的啟動(dòng)方式
如前面所述,長(zhǎng)事務(wù)有這些潛在風(fēng)險(xiǎn)油昂,我當(dāng)然是建議你盡量避免繁疤。其實(shí)很多時(shí)候業(yè)務(wù)開發(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è)線程的自動(dòng)提交關(guān)閉叹放。意味著如果你只執(zhí)行一個(gè)select語(yǔ)句饰恕,這個(gè)事務(wù)就啟動(dòng)了井仰,而且并不會(huì)自動(dòng)提交。這個(gè)事務(wù)持續(xù)存在直到你主動(dòng)執(zhí)行commit或rollback語(yǔ)句俱恶,或者斷開連接。
有些客戶端連接框架會(huì)默認(rèn)連接成功后先執(zhí)行一個(gè)set autocommit=0的命令合是。這就導(dǎo)致接下來的查詢都在事務(wù)中了罪,如果是長(zhǎng)連接聪全,就導(dǎo)致了意外的長(zhǎng)事務(wù)。
因此难礼,我會(huì)建議你總是使用set autocommit=1,通過顯示語(yǔ)句的方式來啟動(dòng)事務(wù)蛾茉。
但是有的開發(fā)同學(xué)會(huì)糾結(jié)"多一次交互"的問題踊餐。對(duì)于一個(gè)需要頻繁使用事務(wù)的業(yè)務(wù),第二種方式每個(gè)事務(wù)在開始時(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ǔ)句的開銷赖条。同時(shí)帶來的好處是從程序開發(fā)的角度明確的知道每個(gè)語(yǔ)句是否處于事務(wù)中。
你可以在information_schema庫(kù)的innodb_trx這個(gè)表中查詢長(zhǎng)事務(wù),比如下面這個(gè)語(yǔ)句纬乍,用于查找持續(xù)時(shí)間超過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è)問題吧。你現(xiàn)在知道了系統(tǒng)里面應(yīng)該避免長(zhǎng)事務(wù)队伟,如果你是業(yè)務(wù)開發(fā)負(fù)責(zé)人同時(shí)也是數(shù)據(jù)庫(kù)負(fù)責(zé)人穴吹,你會(huì)有什么方案來避免出現(xiàn)或者處理這種情況呢?
上期問題
在上期文章的最后嗜侮,我給你留下的問題是一天一備跟一周一備的對(duì)比港令。
好處是"最長(zhǎng)恢復(fù)時(shí)間"更短。即一天一備份時(shí)棘钞,在進(jìn)行恢復(fù)操作時(shí)花費(fèi)的時(shí)間短缠借。
在一天一備的模式里,最壞情況下需要應(yīng)用一天的binlog宜猜。比如泼返,你每天0點(diǎn)做一次全量備份,而要恢復(fù)出一個(gè)到昨天晚上23點(diǎn)的備份姨拥。
一周一備最壞情況就要應(yīng)用一周的binlog了绅喉。
當(dāng)然這個(gè)不是唯一性答案。因?yàn)檫@是需要根據(jù)業(yè)務(wù)重要性來評(píng)估的叫乌,因?yàn)楦l繁全量備份需要消耗更多存儲(chǔ)空間柴罐,所以這個(gè)RTO(恢復(fù)目標(biāo)時(shí)間)是成本換來的。