《Mysql必讀mysql+Spring數(shù)據(jù)庫(kù)隔離級(jí)別與性能分析》要點(diǎn):
本文介紹了Mysql必讀mysql+Spring數(shù)據(jù)庫(kù)隔離級(jí)別與性能分析,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
這里以mysql為例,先明確以下幾個(gè)問題:MYSQL必讀
一.一般項(xiàng)目如果不自己配置事務(wù)的話,一般默認(rèn)的是autocommit,即執(zhí)行完一個(gè)操作后自動(dòng)commit,提交事務(wù).MYSQL必讀
(注:事務(wù)是綁定在數(shù)據(jù)庫(kù)操作上的,也就是當(dāng)程序執(zhí)行(statement.excute等操作)轉(zhuǎn)而到數(shù)據(jù)庫(kù)層面上的時(shí)候,事務(wù)才開始發(fā)生)
當(dāng)然spring可以將幾個(gè)數(shù)據(jù)庫(kù)操作動(dòng)作綁在一個(gè)事務(wù)中,這樣就需要介紹下spring事務(wù)配置方法,下面介紹的是常用方法,其他方法網(wǎng)上有很多.
spring提供了很多事務(wù)配置的策略,很方便,簡(jiǎn)要介紹一下:MYSQL必讀
一般spring配置事務(wù)都是以上的配法,具體參數(shù)的意思有不懂的上網(wǎng)自己查吧,那么需要注意以下幾點(diǎn):(題外話)
1.我習(xí)慣將事務(wù)配置在service上,這時(shí)需要注意,只有service中以save、update等開頭的方法,配置的事務(wù)才有效果.如果service中的方法名不是以save等開頭的,比如taskSave()方法,即使在實(shí)現(xiàn)類中調(diào)用了service中的update方法,配置事務(wù)也失效,我試過.
2.readOnly這個(gè)屬性很有意思,因?yàn)橛昧怂?會(huì)自動(dòng)將數(shù)據(jù)庫(kù)的隔離級(jí)別提高了一級(jí),由提交讀變?yōu)橹貜?fù)讀,這塊我后面說(shuō)明.MYSQL必讀
二.數(shù)據(jù)庫(kù)隔離級(jí)別MYSQL必讀
數(shù)據(jù)庫(kù)隔離級(jí)別主要有以下四個(gè):不可提交讀,提交讀,重復(fù)讀和序列化讀(以下理解可以不看).
1. ISOLATION_READ_UNCOMMITTED: 這是事務(wù)最低的隔離級(jí)別,它充許令外一個(gè)事務(wù)可以看到這個(gè)事務(wù)未提交的數(shù)據(jù).
???? 這種隔離級(jí)別會(huì)產(chǎn)生臟讀,不可重復(fù)讀和幻像讀.
2. ISOLATION_READ_COMMITTED: 保證一個(gè)事務(wù)修改的數(shù)據(jù)提交后才能被另外一個(gè)事務(wù)讀取.另外一個(gè)事務(wù)不能讀取該事務(wù)未提交的數(shù)據(jù)
3. ISOLATION_REPEATABLE_READ: 這種事務(wù)隔離級(jí)別可以防止臟讀,不可重復(fù)讀.但是可能出現(xiàn)幻像讀.
???? 它除了保證一個(gè)事務(wù)不能讀取另一個(gè)事務(wù)未提交的數(shù)據(jù)外,還保證了避免下面的情況產(chǎn)生(不可重復(fù)讀).
4. ISOLATION_SERIALIZABLE 這是花費(fèi)最高代價(jià)但是最可靠的事務(wù)隔離級(jí)別.事務(wù)被處理為順序執(zhí)行.
???? 除了防止臟讀,不可重復(fù)讀外,還避免了幻像讀.
mysql默認(rèn)的隔離級(jí)別是重復(fù)讀,即 ISOLATION_REPEATABLE_READ.MYSQL必讀
注意:其中未提交讀與序列化讀不常用,未提交讀危險(xiǎn)性太高,會(huì)讀到很多臟數(shù)據(jù).而可串行化讀是通過將讀取的每一行數(shù)據(jù)加鎖,以耗費(fèi)性能為代價(jià)換取的,所以使用也很少,大部分?jǐn)?shù)據(jù)庫(kù)的隔離級(jí)別是提交讀,比如oracle、sqlserver.而mysql默認(rèn)的數(shù)據(jù)隔離級(jí)別是可重復(fù)讀.MYSQL必讀
下面我來(lái)結(jié)合項(xiàng)目分析以下調(diào)整數(shù)據(jù)庫(kù)隔離級(jí)別對(duì)性能的影響:
本地mysql數(shù)據(jù)庫(kù)由ISOLATION_REPEATABLE_READ級(jí)別降低到ISOLATION_READ_COMMITTED級(jí)別:MYSQL必讀
場(chǎng)景:未用Spring,用戶A在一個(gè)事務(wù)中對(duì)數(shù)據(jù)庫(kù)發(fā)出兩次查詢請(qǐng)求,在兩次查詢之間,用戶B對(duì)數(shù)據(jù)庫(kù)的記錄進(jìn)行修改.MYSQL必讀
結(jié)果:ISOLATION_REPEATABLE_READ級(jí)別:用戶A兩次查詢結(jié)果不一樣.MYSQL必讀
????????? ISOLATION_READ_COMMITTED級(jí)別:用戶A兩次查詢結(jié)果一樣,因?yàn)閷?duì)記錄進(jìn)行了加鎖操作.MYSQL必讀
以task模塊為例,在本地運(yùn)行任務(wù)首頁(yè),通過對(duì)比分析兩種事務(wù)處理方式得到如下結(jié)果(每次統(tǒng)計(jì)數(shù)據(jù)前均清理瀏覽器緩存,統(tǒng)計(jì)3次取平均值):
發(fā)現(xiàn)降低數(shù)據(jù)庫(kù)事務(wù)的隔離級(jí)別,對(duì)于一些特殊邏輯的操作上,性能有所提升.
但是如果查詢過程中,不涉及同一事務(wù)中多次對(duì)數(shù)據(jù)庫(kù)操作的復(fù)雜邏輯及同一事務(wù)中多次查詢同一結(jié)果集的邏輯,則對(duì)速度的提升效果并不明顯,即事務(wù)進(jìn)行時(shí)對(duì)數(shù)據(jù)集加鎖的時(shí)間是可以忽略的,下面再來(lái)理解一下事務(wù)隔離級(jí)別與鎖的關(guān)系.
談到數(shù)據(jù)庫(kù)隔離級(jí)別,就要說(shuō)一下鎖的概念:
主要分為共享鎖和排他鎖.
共享鎖:由讀表操作加上的鎖,加鎖后其他用戶只能獲取該表或行的共享鎖,不能獲取排它鎖,也就是說(shuō)只能讀不能寫
排它鎖:由寫表操作加上的鎖,加鎖后其他用戶不能獲取該表或行的任何鎖,典型是mysql事務(wù)中.
個(gè)人理解:共享鎖和排他鎖沒有嚴(yán)格的界限,我認(rèn)為應(yīng)該通過結(jié)果確定加的是共享鎖還是排他鎖.
例如:用戶A修改一條數(shù)據(jù),用戶B也修改這條數(shù)據(jù),掛起. 但是B查看這個(gè)數(shù)據(jù)可以,證明A用戶添加了行級(jí)共享鎖.
再例如:用戶A修改一條數(shù)據(jù),用戶B查詢這條數(shù)據(jù)失敗,查詢其他數(shù)據(jù)也失敗.那么肯定A加了表級(jí)排他鎖.
再例如:用戶A修改一條數(shù)據(jù),用戶B查詢記錄可以,但是修改這條記錄不行,修改其他記錄也不行,那么A加了表級(jí)共享鎖.
不同的數(shù)據(jù)隔離級(jí)別,加的鎖是不一樣的.
回到前面的問題,readonly屬性一旦被設(shè)置后,數(shù)據(jù)庫(kù)級(jí)別如果為提交讀,那么同一個(gè)事務(wù)中,如果對(duì)兩次結(jié)果集進(jìn)行查詢,中間間隔修改數(shù)據(jù)庫(kù),那么應(yīng)該會(huì)是同一個(gè)結(jié)果集,相當(dāng)于查詢的時(shí)候采用的是重復(fù)讀的隔離級(jí)別.MYSQL必讀
轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址:
http://www.snjht.com/jiaocheng/4024.html