快捷導(dǎo)航

mysql+Spring數(shù)據(jù)庫隔離級別與性能分析

更新時間：2014年05月01日 23:57:39 作者：

數(shù)據(jù)庫隔離級別與Spring配置事務(wù)的聯(lián)系及性能影響，以下是個人理解，如果有瑕疵請及時指正

這里以mysql為例，先明確以下幾個問題：

一.一般項目如果不自己配置事務(wù)的話，一般默認的是autocommit，即執(zhí)行完一個操作后自動commit，提交事務(wù)。

（注：事務(wù)是綁定在數(shù)據(jù)庫操作上的，也就是當程序執(zhí)行（statement.excute等操作）轉(zhuǎn)而到數(shù)據(jù)庫層面上的時候，事務(wù)才開始發(fā)生）
當然spring可以將幾個數(shù)據(jù)庫操作動作綁在一個事務(wù)中，這樣就需要介紹下spring事務(wù)配置方法，下面介紹的是常用方法，其他方法網(wǎng)上有很多。
spring提供了很多事務(wù)配置的策略，很方便，簡要介紹一下：

復(fù)制代碼代碼如下:

 <property name="transactionAttributes"> 
<props> 
<prop key="save*">PROPAGATION_REQUIRED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="delete*">PROPAGATION_REQUIRED</prop> 
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop> 
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop> 
</props> 

一般spring配置事務(wù)都是以上的配法，具體參數(shù)的意思有不懂的上網(wǎng)自己查吧，那么需要注意以下幾點：（題外話）
1.我習慣將事務(wù)配置在service上，這時需要注意，只有service中以save、update等開頭的方法，配置的事務(wù)才有效果。如果service中的方法名不是以save等開頭的，比如taskSave()方法，即使在實現(xiàn)類中調(diào)用了service中的update方法，配置事務(wù)也失效，我試過。
2.readOnly這個屬性很有意思，因為用了它后，會自動將數(shù)據(jù)庫的隔離級別提高了一級，由提交讀變?yōu)橹貜?fù)讀，這塊我后面說明。

二.數(shù)據(jù)庫隔離級別

數(shù)據(jù)庫隔離級別主要有以下四個：不可提交讀，提交讀，重復(fù)讀和序列化讀（以下理解可以不看）。
1. ISOLATION_READ_UNCOMMITTED：這是事務(wù)最低的隔離級別，它充許令外一個事務(wù)可以看到這個事務(wù)未提交的數(shù)據(jù)。
     這種隔離級別會產(chǎn)生臟讀，不可重復(fù)讀和幻像讀。
2. ISOLATION_READ_COMMITTED：保證一個事務(wù)修改的數(shù)據(jù)提交后才能被另外一個事務(wù)讀取。另外一個事務(wù)不能讀取該事務(wù)未提交的數(shù)據(jù)
3. ISOLATION_REPEATABLE_READ：這種事務(wù)隔離級別可以防止臟讀，不可重復(fù)讀。但是可能出現(xiàn)幻像讀。
     它除了保證一個事務(wù)不能讀取另一個事務(wù)未提交的數(shù)據(jù)外，還保證了避免下面的情況產(chǎn)生(不可重復(fù)讀)。
4. ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務(wù)隔離級別。事務(wù)被處理為順序執(zhí)行。
     除了防止臟讀，不可重復(fù)讀外，還避免了幻像讀。
mysql默認的隔離級別是重復(fù)讀，即 ISOLATION_REPEATABLE_READ。

注意：其中未提交讀與序列化讀不常用，未提交讀危險性太高，會讀到很多臟數(shù)據(jù)。而可串行化讀是通過將讀取的每一行數(shù)據(jù)加鎖，以耗費性能為代價換取的，所以使用也很少，大部分數(shù)據(jù)庫的隔離級別是提交讀，比如oracle、sqlserver。而mysql默認的數(shù)據(jù)隔離級別是可重復(fù)讀。

下面我來結(jié)合項目分析以下調(diào)整數(shù)據(jù)庫隔離級別對性能的影響：
本地mysql數(shù)據(jù)庫由ISOLATION_REPEATABLE_READ級別降低到ISOLATION_READ_COMMITTED級別：

場景：未用Spring，用戶A在一個事務(wù)中對數(shù)據(jù)庫發(fā)出兩次查詢請求，在兩次查詢之間，用戶B對數(shù)據(jù)庫的記錄進行修改。

結(jié)果：ISOLATION_REPEATABLE_READ級別：用戶A兩次查詢結(jié)果不一樣。

ISOLATION_READ_COMMITTED級別：用戶A兩次查詢結(jié)果一樣，因為對記錄進行了加鎖操作。

以task模塊為例，在本地運行任務(wù)首頁，通過對比分析兩種事務(wù)處理方式得到如下結(jié)果(每次統(tǒng)計數(shù)據(jù)前均清理瀏覽器緩存，統(tǒng)計3次取平均值)：

發(fā)現(xiàn)降低數(shù)據(jù)庫事務(wù)的隔離級別，對于一些特殊邏輯的操作上，性能有所提升。
但是如果查詢過程中，不涉及同一事務(wù)中多次對數(shù)據(jù)庫操作的復(fù)雜邏輯及同一事務(wù)中多次查詢同一結(jié)果集的邏輯，則對速度的提升效果并不明顯，即事務(wù)進行時對數(shù)據(jù)集加鎖的時間是可以忽略的，下面再來理解一下事務(wù)隔離級別與鎖的關(guān)系。

談到數(shù)據(jù)庫隔離級別，就要說一下鎖的概念：

主要分為共享鎖和排他鎖。
共享鎖：由讀表操作加上的鎖，加鎖后其他用戶只能獲取該表或行的共享鎖，不能獲取排它鎖，也就是說只能讀不能寫

排它鎖：由寫表操作加上的鎖，加鎖后其他用戶不能獲取該表或行的任何鎖，典型是mysql事務(wù)中。

個人理解：共享鎖和排他鎖沒有嚴格的界限，我認為應(yīng)該通過結(jié)果確定加的是共享鎖還是排他鎖。

例如：用戶A修改一條數(shù)據(jù)，用戶B也修改這條數(shù)據(jù)，掛起。但是B查看這個數(shù)據(jù)可以，證明A用戶添加了行級共享鎖。

再例如：用戶A修改一條數(shù)據(jù)，用戶B查詢這條數(shù)據(jù)失敗，查詢其他數(shù)據(jù)也失敗。那么肯定A加了表級排他鎖。

再例如：用戶A修改一條數(shù)據(jù)，用戶B查詢記錄可以，但是修改這條記錄不行，修改其他記錄也不行，那么A加了表級共享鎖。

不同的數(shù)據(jù)隔離級別，加的鎖是不一樣的。

回到前面的問題，readonly屬性一旦被設(shè)置后，數(shù)據(jù)庫級別如果為提交讀，那么同一個事務(wù)中，如果對兩次結(jié)果集進行查詢，中間間隔修改數(shù)據(jù)庫，那么應(yīng)該會是同一個結(jié)果集，相當于查詢的時候采用的是重復(fù)讀的隔離級別。