您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“MySQL的隔離性與隔離級別”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
提到事務(wù),你肯定會想到ACID
(Atomicity、Consistency、Isolation、Durability,即原子性
、一致性
、隔離性
、持久性
),今天我們就來說說其中Isolation
,也就是隔離性
。
原子性:一個事務(wù)(transaction)中的所有操作,要么全部完成,要么全部不完成,不會結(jié)束在中間某個環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯誤,會被回滾(Rollback)到事務(wù)開始前的狀態(tài),就像這個事務(wù)從來沒有執(zhí)行過一樣。
一致性:在事務(wù)開始之前和事務(wù)結(jié)束以后,。這表示寫入的資料必須完數(shù)據(jù)庫的完整性沒有被破壞全符合所有的預(yù)設(shè)規(guī)則,這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫可以自發(fā)性地完成預(yù)定的工作。
隔離性:數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進(jìn)行讀寫和修改的能力,隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級別,包括讀未提交(Read uncommitted)、讀提交(read committed)、可重復(fù)讀(repeatable read)和串行化(Serializable)。
持久性:事務(wù)處理結(jié)束后,對數(shù)據(jù)的的,即便系統(tǒng)修改就是永久故障也不會丟失。
當(dāng)數(shù)據(jù)庫上有多個事務(wù)同時執(zhí)行的時候,就可能出現(xiàn)臟讀
(dirty read)、不可重復(fù)讀
(non-repeatable read)、幻讀
(phantom read)的問題,為了解決這些問題,就有了隔離級別
的概念。
隔離性 | 具體含義 |
---|---|
臟讀 | B事務(wù)更改數(shù)據(jù)還未提交,A事務(wù)已經(jīng)看到并且用了。B事務(wù)如果回滾,則A事務(wù)做錯了 |
不可重復(fù)讀 | 不可重復(fù)讀的重點(diǎn)是修改: 同樣的條件, 你讀取過的數(shù)據(jù), 再次讀取出來發(fā)現(xiàn)值不一樣了,只需要鎖住滿足條件的記錄 |
幻讀 | 幻讀的重點(diǎn)在于新增或者刪除同樣的條件, 第1次和第2次讀出來的記錄數(shù)不一樣 ,要鎖住滿足條件及其相近的記錄 |
在談隔離級別之前,你首先要知道,你隔離得越嚴(yán)實(shí),效率就會越低
。因此很多時候,我們都要在二者之間尋找一個平衡點(diǎn)。SQL標(biāo)準(zhǔn)的事務(wù)隔離級別由低到高
包括:
讀未提交:是指一個事務(wù)還沒提交時,它做的變更就能被別的事務(wù)看到。
讀提交:是指一個事務(wù)提交之后,它做的變更才會被其他事務(wù)看到。
可重復(fù)讀(默認(rèn)級別):是指一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù),總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)是一致的。當(dāng)然在可重復(fù)讀隔離級別下,未提交變更對其他事務(wù)也是不可見的。
串行化:顧名思義是對于同一行記錄,寫會加寫鎖,讀會加讀鎖。對應(yīng)一個記錄會加讀寫鎖,出現(xiàn)沖突的時候,后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成才能繼續(xù)執(zhí)行。
用大白話說下上述的含義:
讀未提交:別人改數(shù)據(jù)的事務(wù)尚未提交,我在我的事務(wù)中也能讀到。
讀已提交(Oracle默認(rèn)):別人改數(shù)據(jù)的事務(wù)已經(jīng)提交,我在我的事務(wù)中才能讀到。
可重復(fù)讀(MySQL默認(rèn)):別人改數(shù)據(jù)的事務(wù)已經(jīng)提交,我在我的事務(wù)中也不去讀,以此保證重復(fù)讀一致性。
串行:我的事務(wù)尚未提交,別人就別想改數(shù)據(jù)。
這4種隔離級別,并行性能依次降低,安全性依次提高。
其中讀提交
和可重復(fù)讀
比較難理解,所以我用一個例子說明這幾種隔離級別。假設(shè)數(shù)據(jù)表T
中只有一列,其中一行的值為1,下面是按照時間順序執(zhí)行兩個事務(wù)的行為。
mysql> create table T(c int) engine=InnoDB;insert into T(c) values(1);
我們來看看在不同的隔離級別下,事務(wù)A會有哪些不同的返回結(jié)果,也就是圖里面V1、V2、V3的返回值分別是什么。
隔離級別 | 結(jié)果 |
---|---|
讀未提交 | 這時候事務(wù)B雖然還沒有提交,但是結(jié)果已經(jīng)被A看到了。V1=2、V2=2、V3=2 |
讀提交 | 事務(wù)B的更新在提交后才能被A看到。V1=1、V2=2、V3=2 |
可重復(fù)讀 | 事務(wù)在執(zhí)行期間看到的數(shù)據(jù)前后必須是一致的。V1=1、V2=1、V3=2 |
串行化 | 則在事務(wù)B執(zhí)行將1改成2的時候,會被鎖住。直到事務(wù)A提交后,事務(wù)B才可以繼續(xù)執(zhí)行。V1=1、V2=1、V3=2 |
在實(shí)現(xiàn)上,數(shù)據(jù)庫里面會創(chuàng)建一個視圖
,訪問的時候以視圖的邏輯結(jié)果為準(zhǔn)。
讀未提交
隔離級別下直接返回記錄上的最新值,沒有視圖概念
在讀提交
隔離級別下,這個視圖(read-view)是在每個SQL語句開始執(zhí)行的時候創(chuàng)建的.
在可重復(fù)讀
隔離級別下,這個視圖是在事務(wù)啟動時創(chuàng)建的,整個事務(wù)存在期間都用這個視圖。
在串行化
隔離級別下直接用加鎖的方式來避免并行訪問。
我們可以看到在不同的隔離級別下,數(shù)據(jù)庫行為是有所不同的。Oracle數(shù)據(jù)庫的默認(rèn)隔離級別其實(shí)就是讀提交
,因此對于一些從Oracle遷移到MySQL(默認(rèn)可重復(fù)讀)的應(yīng)用,為保證數(shù)據(jù)庫隔離級別的一致,你一定要記得將MySQL的隔離級別設(shè)置為讀提交
。
mysql> show variables like 'transaction_isolation';+-----------------------+----------------+| Variable_name | Value |+-----------------------+----------------+| transaction_isolation | READ-COMMITTED |+-----------------------+----------------+
總結(jié)來說,存在即合理,哪個隔離級別都有它自己的使用場景,你要根據(jù)自己的業(yè)務(wù)情況來定。我想你可能會問那什么時候需要可重復(fù)讀
的場景呢?我們來看一個數(shù)據(jù)校對邏輯的案例。
假設(shè)你在管理一個 個人銀行賬戶表。一個表存了每個月月底的余額,一個表存了賬單明細(xì)。這時候你要做數(shù)據(jù)校對,也就是判斷上個月的余額和當(dāng)前余額的差額,是否與本月的賬單明細(xì)一致。你一定希望在校對過程中,即使有用戶發(fā)生了一筆新的交易,也不影響你的校對結(jié)果。
這時候使用可重復(fù)讀
隔離級別就很方便。事務(wù)啟動時的視圖可以認(rèn)為是靜態(tài)的,不受其他事務(wù)更新的影響。
理解了事務(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-view A,要得到1,就必須將當(dāng)前值依次執(zhí)行圖中所有的回滾操作得到。
同時你會發(fā)現(xiàn),即使現(xiàn)在有另外一個事務(wù)正在將4改成5,這個事務(wù)跟read-view A、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)致大量占用存儲空間。
在MySQL 5.5及以前的版本,回滾日志是跟數(shù)據(jù)字典一起放在ibdata文件里的,即使長事務(wù)最終提交,回滾段被清理,文件也不會變小。我見過數(shù)據(jù)只有20GB,而回滾段有200GB的庫。最終只好為了清理回滾段,重建整個庫。
除了對回滾段的影響,長事務(wù)還占用鎖資源,也可能拖垮整個庫,這個我們會在后面講鎖的時候展開。
如前面所述,長事務(wù)有這些潛在風(fēng)險,我當(dāng)然是建議你盡量避免。其實(shí)很多時候業(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 語句,或者斷開連接。
有些客戶端連接框架會默認(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
你現(xiàn)在知道了系統(tǒng)里面應(yīng)該避免長事務(wù),如果你是業(yè)務(wù)開發(fā)負(fù)責(zé)人同時也是數(shù)據(jù)庫負(fù)責(zé)人,你會有什么方案來避免出現(xiàn)或者處理這種情況呢?
這個問題,我們可以從應(yīng)用開發(fā)端
和數(shù)據(jù)庫端
來看。
首先,從應(yīng)用開發(fā)端
來看:
確認(rèn)是否使用了set autocommit=0。這個確認(rèn)工作可以在測試環(huán)境中開展,把MySQL的general_log開起來,然后隨便跑一個業(yè)務(wù)邏輯,通過general_log的日志來確認(rèn)。一般框架如果會設(shè)置這個值,也就會提供參數(shù)來控制行為,你的目標(biāo)就是把它改成1。
確認(rèn)是否有不必要的只讀事務(wù)。有些框架會習(xí)慣不管什么語句先用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è)置后清理起來更方便。
“MySQL的隔離性與隔離級別”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。