www.99久久.com,www.天天操,а√中文在线8

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

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

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

復制代碼代碼如下:

	
	 <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配置事務都是以上的配法，具體參數的意思有不懂的上網自己查吧，那么需要注意以下幾點：（題外話）
1.我習慣將事務配置在service上，這時需要注意，只有service中以save、update等開頭的方法，配置的事務才有效果。如果service中的方法名不是以save等開頭的，比如taskSave()方法，即使在實現類中調用了service中的update方法，配置事務也失效，我試過。
2.readOnly這個屬性很有意思，因為用了它后，會自動將數據庫的隔離級別提高了一級，由提交讀變為重復讀，這塊我后面說明。

二.數據庫隔離級別

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

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

下面我來結合項目分析以下調整數據庫隔離級別對性能的影響：
本地mysql數據庫由ISOLATION_REPEATABLE_READ級別降低到ISOLATION_READ_COMMITTED級別：

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

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

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

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

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

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

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

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

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

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

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

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

不同的數據隔離級別，加的鎖是不一樣的。

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