資料庫隔離級別與 Spring 事務配置效能分析

資料庫隔離級別直接影響並發效能與資料一致性，Spring 事務配置進一步封裝隔離行為。本文以 MySQL 為例，解析四大隔離級別特性、Spring 宣告式事務配置要點、readOnly 屬性對隔離級別的隱含影響，並實測隔離級別調整對特定業務場景的效能差異。

一、核心概念釐清

1. 預設自動提交： 未配置事務時，每條 SQL 隱式開啟/提交事務 (autocommit=1)。
2. Spring 事務邊界： 透過 AOP 將多個資料庫操作納入單一事務，事務在 Service 方法進入時開啟，正常返回提交、拋出異常回滾。
3. 事務屬性傳播： PROPAGATION_REQUIRED (預設，支援巢狀)、PROPAGATION_REQUIRES_NEW (掛起當前開新)、PROPAGATION_NESTED (巢狀保存點) 等。

二、四大隔離級別詳解

關鍵差異：

• RC vs RR： RC 只鎖修改行，讀取不加鎖；RR 讀取加共享鎖 (快照讀) 或間隙鎖 (當前讀)，防止幻讀但增加鎖競爭。
• MySQL RR 實現： MVCC (多版本並發控制) + Next-Key Lock，普通 SELECT 為快照讀 (不加鎖)，鎖定讀 (LOCK IN SHARE MODE/FOR UPDATE) 才加鎖。

三、Spring 事務配置實戰

3.1 經典 XML 配置

<tx:advice id="txAdvice" transaction-manager="transactionManager">
  <tx:attributes>
    <tx:method name="save*" propagation="REQUIRED" />
    <tx:method name="insert*" propagation="REQUIRED" />
    <tx:method name="update*" propagation="REQUIRED" />
    <tx:method name="delete*" propagation="REQUIRED" />
    <tx:method name="get*" propagation="REQUIRED" read-only="true" />
    <tx:method name="find*" propagation="REQUIRED" read-only="true" />
    <tx:method name="*" propagation="REQUIRED" />
  </tx:attributes>
</tx:advice>

<aop:config>
  <aop:pointcut id="serviceMethods" expression="execution(* com.example.service.*.*(..))" />
  <aop:advisor advice-ref="txAdvice" pointcut-ref="serviceMethods" />
</aop:config>

3.2 註解配置 (Spring Boot 推薦)

@Service
@Transactional(readOnly = true)  // 類級別預設唯讀
public class UserService {
    @Transactional(readOnly = false)  // 覆蓋類級別
    public void saveUser(User u) { ... }
    
    public User getUser(Long id) { ... }  // 繼承類級別 readOnly=true
}

3.3 關鍵避坑指南

1. 方法名匹配： 僅匹配 save*、update* 等前綴的方法生效，taskSave() 不會觸發事務，建議統一命名規範或改用註解。
2. readOnly 真相：
   • Hibernate/JPA：FlushMode 設為 MANUAL，跳過髒檢查，效能提升。
   • MyBatis/JDBC：不會自動提升隔離級別，僅作為提示傳給驅動 (部分驅動優化)。
   • 錯誤認知： 「readOnly 會將隔離級別從 RC 提升到 RR」——錯誤。隔離級別由 @Transactional(isolation = Isolation.REPEATABLE_READ) 顯式指定，與 readOnly 無關。
3. 異常回滾： 預設僅回滾 RuntimeException、Error，受檢異常需 rollbackFor = Exception.class。

四、實測：隔離級別調整效能影響

場景

本地 MySQL，同一事務內用戶 A 兩次查詢，間隙用戶 B 修改記錄。

結果對比

結論

• 降級至 RC 在同一事務多次查詢同一結果集且間隙有寫入的場景顯著提升效能 (鎖持有時間短、衝突少)。
• 單次查詢或無並發寫入場景，差異可忽略。
• RR 的間隙鎖在大範圍篩選/批次更新時易導致鎖等待甚至死鎖，RC 可緩解。

五、鎖與隔離級別的深層關係

實務判斷鎖類型口訣：

• A 改行，B 改同行 → 掛起 → 行 X 鎖
• A 改行，B 查同行 → 正常 → 行 S 鎖 (RR 當前讀) 或 無鎖 (RC/RR 快照讀)
• A 改行，B 查全表掛起 → 表 X 鎖 (或意向鎖升級)
• A 改行，B 查其他行正常、改其他行掛起 → 表 S 鎖 (罕見，通常為元資料鎖)

六、綜合建議

1. 預設堅持 RR： MySQL 預設 RR + MVCC 已平衡一致性與效能，無特殊理由勿動。
2. 高併發寫入熱點表： 嘗試 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED + innodb_locks_unsafe_for_binlog=1 (5.6+ 已廢棄，改用 binlog_format=ROW 避免 GAP 鎖)。
3. Spring 配置： 類級別 @Transactional(readOnly=true)，寫方法覆蓋 readOnly=false，顯式指定 isolation 僅在極少數場景。
4. 監控指標： Innodb_row_lock_waits、Innodb_row_lock_time_avg、Innodb_deadlocks，鎖等待上升時優先優化 SQL/索引，而非降級隔離級別。

隔離級別調優是「最後手段」，索引優化、SQL 重寫、架構拆分才是正道。理解鎖與 MVCC 底層機制，方能在關鍵時刻做出正確權衡。