本文結合 MySQL 與 Spring 實務，系統梳理四大隔離等級行為差異、Spring 宣告式事務配置要點，並以實測數據量化降低隔離等級對效能的影響。

四大隔離等級速查表

等級	髒讀	不可重複讀	幻讀	鎖特性
READ UNCOMMITTED	✅	✅	✅	無共享鎖，並發最高
READ COMMITTED	❌	✅	✅	讀取瞬間加共享鎖，讀完即釋放
REPEATABLE READ (MySQL 預設)	❌	❌	✅ (InnoDB Next-Key Lock 緩解)	首次讀取加共享鎖至事務結束
SERIALIZABLE	❌	❌	❌	全表/範圍鎖，串行執行

Spring 宣告式事務配置精要

<tx:advice id="txAdvice" transaction-manager="transactionManager">
  <tx:attributes>
    <tx:method name="save*" 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:attributes>
</tx:advice>

關鍵陷阱：方法名必須符合模式（如 save*），若 Service 方法命名為 taskSave() 將不匹配，事務失效。建議統一命名規範或改用註解 @Transactional。

read-only="true" 的隱藏行為

啟用 readOnly 時，Spring 會將該事務的隔離等級自動提升一級（READ COMMITTED → REPEATABLE READ），以確保同一事務內多次查詢結果一致。若資料庫預設已是 RR，則無額外影響。

實測：RR → RC 效能差異

場景：Task 模組首頁，同一事務內兩次查詢中間夾帶他人更新。

• RR：兩次查詢結果不一致（發生不可重複讀），需持有鎖至事務結束。
• RC：兩次查詢結果一致（因鎖行級共享鎖），鎖持有時間極短。

結果：含「同一事務多次查詢同一結果集」的複雜邏輯，降級至 RC 可明顯降低鎖持有時間、提升吞吐；單純單次查詢場景差異可忽略。

鎖視角重新理解隔離等級

• 共享鎖 (S)：SELECT ... LOCK IN SHARE MODE / 一般 SELECT (RC/RR)；相容 S，不相容 X。
• 排他鎖 (X)：INSERT/UPDATE/DELETE / SELECT ... FOR UPDATE；與 S、X 皆不相容。
• 實務判斷鎖類型：觀察並發會話能否「讀/寫」同一行/表，反推鎖模式與粒度。

最佳實踐建議

1. 核心交易保持 RR，確保一致性；報表、查詢密集型服務可嘗試 RC。
2. Spring 事務務必加在 Service 層，方法命名遵循慣例或改用 @Transactional。
3. 善用 readOnly=true 優化唯讀事務，減少鎖爭用。
4. 監控 Innodb_row_lock_waits、Innodb_row_lock_time_avg 持續調優。