03講事務(wù)隔離:為什么你改了我還看不見

簡單來說,事務(wù)就是要保證一組數(shù)據(jù)庫操作部翘,要么全部成功,要么全部失敗响委。在MySQL中新思,事務(wù)支持是在引擎層實現(xiàn)的。

只有InnoDB支持事務(wù)赘风。

1 隔離性與隔離級別

事務(wù)有關(guān)的概念:
ACID(Atomicity夹囚、Consistency、Isolation邀窃、Durability荸哟,即原子性、一致性瞬捕、隔離性鞍历、持久性)。

當數(shù)據(jù)庫上有多個事務(wù)同時執(zhí)行的時候肪虎,就可能出現(xiàn)臟讀(dirty read)劣砍、不可重復(fù)讀(non-repeatable read)、幻讀(phantom read)的問題扇救,為了解決這些問題刑枝,就有了“隔離級別”的概念香嗓。

在談隔離級別之前,你首先要知道装畅,你隔離得越嚴實靠娱,效率就會越低。因此很多時候掠兄,我們都要在二者之間尋找一個平衡點像云。

SQL標準的事務(wù)隔離級別包括:

讀未提交(read uncommitted)、讀提交(read committed)蚂夕、可重復(fù)讀(repeatable read)和串行化(serializable )苫费。

  • 讀未提交是指,一個事務(wù)還沒提交時双抽,它做的變更就能被別的事務(wù)看到百框。
  • 讀提交(oracle默認的隔離級別)是指,一個事務(wù)提交之后牍汹,它做的變更才會被其他事務(wù)看到铐维。
  • 可重復(fù)讀(mysql默認的隔離級別)是指,一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)慎菲,總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)是一致的嫁蛇。當然在可重復(fù)讀隔離級別下,未提交變更對其他事務(wù)也是不可見的露该。
  • 串行化睬棚,顧名思義是對于同一行記錄,“寫”會加“寫鎖”解幼,“讀”會加“讀鎖”抑党。當出現(xiàn)讀寫鎖沖突的時候,后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成撵摆,才能繼續(xù)執(zhí)行底靠。
image.png

我們來看看在不同的隔離級別下,事務(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砌们。

事務(wù)在實現(xiàn)上,數(shù)據(jù)庫里面會創(chuàng)建一個視圖搁进,訪問的時候以視圖的邏輯結(jié)果為準浪感。

  • 在“可重復(fù)讀”隔離級別下,這個視圖是在事務(wù)啟動時創(chuàng)建的饼问,整個事務(wù)存在期間都用這個視圖篮撑。
  • 在“讀提交”隔離級別下,這個視圖是在每個SQL語句開始執(zhí)行的時候創(chuàng)建的匆瓜。
  • “讀未提交”隔離級別下直接返回記錄上的最新值赢笨,沒有視圖概念
  • “串行化”隔離級別下直接用加鎖的方式來避免并行訪問。

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

配置的方式是拇砰,將啟動參數(shù)transaction-isolation的值設(shè)置成READ-COMMITTED梅忌。你可以用show variables來查看當前的值狰腌。

mysql> show variables like 'transaction_isolation';

+-----------------------+----------------+

| Variable_name | Value |

+-----------------------+----------------+

| transaction_isolation | READ-COMMITTED |

+-----------------------+----------------+

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

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

這時候使用“可重復(fù)讀”隔離級別就很方便。事務(wù)啟動時的視圖可以認為是靜態(tài)的究恤,不受其他事務(wù)更新的影響俭令。

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

理解了事務(wù)的隔離級別,我們再來看看事務(wù)隔離具體是怎么實現(xiàn)的部宿。這里我們展開說明“可重復(fù)讀”抄腔。

在MySQL中,實際上每條記錄在更新的時候都會同時記錄一條回滾操作理张。記錄上的最新值赫蛇,通過回滾操作,都可以得到前一個狀態(tài)的值雾叭。

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

image.png

當前值是4,但是在查詢這條記錄的時候移迫,不同時刻啟動的事務(wù)會有不同的read-view旺嬉。如圖中看到的,在視圖A厨埋、B邪媳、C里面,這一個記錄的值分別是1、2雨效、4迅涮,同一條記錄在系統(tǒng)中可以存在多個版本,就是數(shù)據(jù)庫的多版本并發(fā)控制(MVCC)徽龟。對于read-view A叮姑,要得到1,就必須將當前值依次執(zhí)行圖中所有的回滾操作得到顿肺。

同時你會發(fā)現(xiàn)戏溺,即使現(xiàn)在有另外一個事務(wù)正在將4改成5渣蜗,這個事務(wù)跟read-view A屠尊、B、C對應(yīng)的事務(wù)是不會沖突的耕拷。

你一定會問讼昆,回滾日志總不能一直保留吧,什么時候刪除呢骚烧?答案是浸赫,在不需要的時候才刪除。也就是說赃绊,系統(tǒng)會判斷既峡,當沒有事務(wù)再需要用到這些回滾日志時,回滾日志會被刪除碧查。

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

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

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

在MySQL 5.5及以前的版本盼砍,回滾日志是跟數(shù)據(jù)字典一起放在ibdata文件里的,即使長事務(wù)最終提交逝她,回滾段被清理衬廷,文件也不會變小。我見過數(shù)據(jù)只有20GB汽绢,而回滾段有200GB的庫吗跋。最終只好為了清理回滾段,重建整個庫。

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

3 事務(wù)的啟動方式

如前面所述蜕猫,長事務(wù)有這些潛在風險,我當然是建議你盡量避免哎迄。其實很多時候業(yè)務(wù)開發(fā)同學(xué)并不是有意使用長事務(wù)回右,通常是由于誤用所致。MySQL的事務(wù)啟動方式有以下幾種:

顯式啟動事務(wù)語句漱挚, begin 或 start transaction翔烁。配套的提交語句是commit,回滾語句是rollback旨涝。

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

有些客戶端連接框架會默認連接成功后先執(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

4 小結(jié)

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

我給你留一個問題吧。你現(xiàn)在知道了系統(tǒng)里面應(yīng)該避免長事務(wù)是辕,如果你是業(yè)務(wù)開發(fā)負責人同時也是數(shù)據(jù)庫負責人囤热,你會有什么方案來避免出現(xiàn)或者處理這種情況呢?

首先免糕,從應(yīng)用開發(fā)端來看:

確認是否使用了set autocommit=0赢乓。這個確認工作可以在測試環(huán)境中開展忧侧,把MySQL的general_log開起來石窑,然后隨便跑一個業(yè)務(wù)邏輯,通過general_log的日志來確認蚓炬。一般框架如果會設(shè)置這個值松逊,也就會提供參數(shù)來控制行為,你的目標就是把它改成1肯夏。

確認是否有不必要的只讀事務(wù)经宏。有些框架會習慣不管什么語句先用begin/commit框起來。我見過有些是業(yè)務(wù)并沒有這個需要驯击,但是也把好幾個select語句放到了事務(wù)中烁兰。這種只讀事務(wù)可以去掉。

業(yè)務(wù)連接數(shù)據(jù)庫的時候徊都,根據(jù)業(yè)務(wù)本身的預(yù)估沪斟,通過SET MAX_EXECUTION_TIME命令,來控制每個語句執(zhí)行的最長時間暇矫,避免單個語句意外執(zhí)行太長時間主之。(為什么會意外?在后續(xù)的文章中會提到這類案例)

其次李根,從數(shù)據(jù)庫端來看:

監(jiān)控 information_schema.Innodb_trx表槽奕,設(shè)置長事務(wù)閾值,超過就報警/或者kill房轿;

Percona的pt-kill這個工具不錯粤攒,推薦使用所森;

在業(yè)務(wù)功能測試階段要求輸出所有的general_log,分析日志行為提前發(fā)現(xiàn)問題夯接;

如果使用的是MySQL 5.6或者更新版本必峰,把innodb_undo_tablespaces設(shè)置成2(或更大的值)。如果真的出現(xiàn)大事務(wù)導(dǎo)致回滾段過大钻蹬,這樣設(shè)置后清理起來更方便吼蚁。

讀未提交:別人改數(shù)據(jù)的事務(wù)尚未提交,我在我的事務(wù)中也能讀到问欠。
讀已提交:別人改數(shù)據(jù)的事務(wù)已經(jīng)提交肝匆,我在我的事務(wù)中才能讀到。
可重復(fù)讀:別人改數(shù)據(jù)的事務(wù)已經(jīng)提交顺献,我在我的事務(wù)中也不去讀旗国。
串行:我的事務(wù)尚未提交,別人就別想改數(shù)據(jù)注整。
這4種隔離級別能曾,并行性能依次降低,安全性依次提高肿轨。

1寿冕、事務(wù)的特性:原子性、一致性椒袍、隔離性驼唱、持久性
2、多事務(wù)同時執(zhí)行的時候驹暑,可能會出現(xiàn)的問題:臟讀玫恳、不可重復(fù)讀、幻讀
3优俘、事務(wù)隔離級別:讀未提交京办、讀提交、可重復(fù)讀帆焕、串行化
4惭婿、不同事務(wù)隔離級別的區(qū)別:
讀未提交:一個事務(wù)還未提交,它所做的變更就可以被別的事務(wù)看到
讀提交:一個事務(wù)提交之后视搏,它所做的變更才可以被別的事務(wù)看到
可重復(fù)讀:一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)是一致的审孽。未提交的更改對其他事務(wù)是不可見的
串行化:對應(yīng)一個記錄會加讀寫鎖,出現(xiàn)沖突的時候浑娜,后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成才能繼續(xù)執(zhí)行
5佑力、配置方法:啟動參數(shù)transaction-isolation
6、事務(wù)隔離的實現(xiàn):每條記錄在更新的時候都會同時記錄一條回滾操作筋遭。同一條記錄在系統(tǒng)中可以存在多個版本打颤,這就是數(shù)據(jù)庫的多版本并發(fā)控制(MVCC)暴拄。
7、回滾日志什么時候刪除编饺?系統(tǒng)會判斷當沒有事務(wù)需要用到這些回滾日志的時候乖篷,回滾日志會被刪除。
8透且、什么時候不需要了撕蔼?當系統(tǒng)里么有比這個回滾日志更早的read-view的時候。
9秽誊、為什么盡量不要使用長事務(wù)鲸沮。長事務(wù)意味著系統(tǒng)里面會存在很老的事務(wù)視圖,在這個事務(wù)提交之前锅论,回滾記錄都要保留讼溺,這會導(dǎo)致大量占用存儲空間。除此之外最易,長事務(wù)還占用鎖資源怒坯,可能會拖垮庫。
10藻懒、事務(wù)啟動方式:一剔猿、顯式啟動事務(wù)語句,begin或者start transaction,提交commit束析,回滾rollback艳馒;二憎亚、set autocommit=0员寇,該命令會把這個線程的自動提交關(guān)掉。這樣只要執(zhí)行一個select語句第美,事務(wù)就啟動蝶锋,并不會自動提交,直到主動執(zhí)行commit或rollback或斷開連接什往。
11扳缕、建議使用方法一,如果考慮多一次交互問題别威,可以使用commit work and chain語法躯舔。在autocommit=1的情況下用begin顯式啟動事務(wù),如果執(zhí)行commit則提交事務(wù)省古。如果執(zhí)行commit work and chain則提交事務(wù)并自動啟動下一個事務(wù)粥庄。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市豺妓,隨后出現(xiàn)的幾起案子惜互,更是在濱河造成了極大的恐慌布讹,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,651評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件训堆,死亡現(xiàn)場離奇詭異描验,居然都是意外死亡,警方通過查閱死者的電腦和手機坑鱼,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,468評論 3 392
  • 文/潘曉璐 我一進店門膘流,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人鲁沥,你說我怎么就攤上這事睡扬。” “怎么了黍析?”我有些...
    開封第一講書人閱讀 162,931評論 0 353
  • 文/不壞的土叔 我叫張陵卖怜,是天一觀的道長。 經(jīng)常有香客問我阐枣,道長马靠,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,218評論 1 292
  • 正文 為了忘掉前任蔼两,我火速辦了婚禮甩鳄,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘额划。我一直安慰自己妙啃,他們只是感情好,可當我...
    茶點故事閱讀 67,234評論 6 388
  • 文/花漫 我一把揭開白布俊戳。 她就那樣靜靜地躺著揖赴,像睡著了一般。 火紅的嫁衣襯著肌膚如雪抑胎。 梳的紋絲不亂的頭發(fā)上燥滑,一...
    開封第一講書人閱讀 51,198評論 1 299
  • 那天,我揣著相機與錄音阿逃,去河邊找鬼铭拧。 笑死,一個胖子當著我的面吹牛恃锉,可吹牛的內(nèi)容都是我干的搀菩。 我是一名探鬼主播,決...
    沈念sama閱讀 40,084評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼破托,長吁一口氣:“原來是場噩夢啊……” “哼肪跋!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起炼团,我...
    開封第一講書人閱讀 38,926評論 0 274
  • 序言:老撾萬榮一對情侶失蹤澎嚣,失蹤者是張志新(化名)和其女友劉穎疏尿,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體易桃,經(jīng)...
    沈念sama閱讀 45,341評論 1 311
  • 正文 獨居荒郊野嶺守林人離奇死亡褥琐,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,563評論 2 333
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了晤郑。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片敌呈。...
    茶點故事閱讀 39,731評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖造寝,靈堂內(nèi)的尸體忽然破棺而出磕洪,到底是詐尸還是另有隱情,我是刑警寧澤诫龙,帶...
    沈念sama閱讀 35,430評論 5 343
  • 正文 年R本政府宣布析显,位于F島的核電站,受9級特大地震影響签赃,放射性物質(zhì)發(fā)生泄漏谷异。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,036評論 3 326
  • 文/蒙蒙 一锦聊、第九天 我趴在偏房一處隱蔽的房頂上張望歹嘹。 院中可真熱鬧,春花似錦孔庭、人聲如沸尺上。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,676評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽怎抛。三九已至,卻和暖如春构资,著一層夾襖步出監(jiān)牢的瞬間抽诉,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,829評論 1 269
  • 我被黑心中介騙來泰國打工吐绵, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人河绽。 一個月前我還...
    沈念sama閱讀 47,743評論 2 368
  • 正文 我出身青樓己单,卻偏偏與公主長得像,于是被迫代替她去往敵國和親耙饰。 傳聞我的和親對象是個殘疾皇子纹笼,可洞房花燭夜當晚...
    茶點故事閱讀 44,629評論 2 354