資料庫隔離等級（mysql+Spring）與效能分析

資料庫隔離等級與Spring配置事務的聯絡及效能影響，以下是個人理解，如果有瑕疵請及時指正。 這裡以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事務中。

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

例如：使用者A修改一條資料，使用者B也修改這條資料，掛起。 但是B查看這個資料可以，證明A使用者添加了行級共用鎖定。

再例如：使用者A修改一條資料，使用者B查詢這條資料失敗，查詢其他資料也失敗。那麼肯定A加了表級獨佔鎖定。

再例如：使用者A修改一條資料，使用者B查詢記錄可以，但是修改這條記錄不行，修改其他記錄也不行，那麼A加了表級共用鎖定。

不同的資料隔離等級，加的鎖是不一樣的。

回到前面的問題，readonly屬性一旦被設定後，資料庫層級如果為提交讀，那麼同一個事務中，如果對兩次結果集進行查詢，中間間隔修改資料庫，那麼應該會是同一個結果集，相當於查詢的時候採用的是重複讀的隔離等級。