---

前言

在開發過程中，遇到多個數據庫操作的時候往往只知道加上@transactional注解（spring框架）但是沒有系統學習數據庫的事務知識以及各種用法，本文會舉例介紹數據庫中事務的概念以及用法

---

一、事務是什么？

在實際的項目開發過程中會涉及很多不可分割的數據庫操作，如轉賬業務的進賬和出帳，要么全部執行成功，要么全部失敗回滾。這樣一些的對數據庫操作的集合就叫事務。現在假設數據庫中有一個表accounts

balance	user_id
1000	1
100	2

在數據庫中執行一段事務的sql如下：

-- 顯式事務示例
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
COMMIT; -- 或 ROLLBACK 回滾

很多人會覺得這里的COMMIT或者ROLLBACK之前，數據庫操作只是在內存中，并沒有更改表中的數據，需要注意的是，這里的COMMIT或者ROLLBACK 之前，數據已經是持久化了，也就是寫入了磁盤（數據庫表中）。

二、事務的特性

根據對事務的理解，可以歸納出事務應該具有的特性
原子性（Atomicity）：事務被視為不可分割的最小單元，要么全部提交成功，要么全部失敗回滾。
一致性（Consistency）：事務執行前后，數據庫從一個一致狀態轉變為另一個一致狀態。
隔離性（Isolation）：多個事務并發執行時，一個事務的操作不應影響其他事務。
持久性（Durability）：事務提交后，其對數據的修改是永久性的。

2.1隔離性

在上述特性中比較難理解的應該是隔離性，可以想象這樣一個場景：
因為網絡延遲或者條件異常，事務A未提交還沒來得及回滾

-- 事務A
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;

事務B開始查詢事務，查詢的結果就是balance = balance - 100

-- 事務B
BEGIN TRANSACTION;
select balance WHERE user_id = 1 from accounts;
commit;

事務A回滾，此刻a,b兩個事務間就發生了干擾，a的事務的提交影響了b事務對數據庫的正常讀取。

-- 事務A
ROLLBACK ;--回滾

所以隔離性就是指的的是a事務對與b事務的互不影響的程度。

2.2事務的隔離級別

事務的隔離級別也可以叫做事務的互不影響程度的級別。
讀未提交（Read Uncommitted）：影響程度最高，即使事務沒有commit，另外的事務也可以讀到，可能導致臟讀。

-- ----------------------
-- 窗口1（事務A）
-- ----------------------
-- 設置隔離級別為讀未提交
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;-- 修改A賬戶余額（未提交）
UPDATE account SET balance = 800 WHERE name = 'A賬戶';
SELECT * FROM account;  -- 查看修改后結果：A賬戶800-- ----------------------
-- 窗口2（事務B）
-- ----------------------
-- 設置隔離級別為讀未提交
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;-- 查詢A賬戶余額（讀到未提交的數據）
SELECT * FROM account;  -- 結果：A賬戶800（臟讀）-- 窗口1（事務A）回滾
ROLLBACK;-- 窗口2再次查詢
SELECT * FROM account;  -- 結果：A賬戶恢復1000（臟讀數據消失）

讀已提交（Read Committed）：只能讀取已提交的數據，避免臟讀但可能出現不可重復讀（一個事務內的多次查詢結果不一致）。即b開啟事務
進行第一次查詢，此時a事務開啟事務，a更改完數據后，事務提交，b開啟第二次查詢，查詢結果不一致。

-- ----------------------
-- 窗口1（事務A）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION; --設置讀已提交的隔離級別-- 修改A賬戶余額并提交
UPDATE account SET balance = 800 WHERE name = 'A賬戶';
COMMIT;  -- 提交事務-- ----------------------
-- 窗口2（事務B）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;-- 第一次查詢（事務A未提交時）
SELECT * FROM account;  -- 結果：A賬戶1000-- 此時事務A已提交...-- 第二次查詢（事務A已提交）
SELECT * FROM account;  -- 結果：A賬戶800（不可重復讀）ROLLBACK;

可重復讀（Repeatable Read）：確保同一事務多次讀取結果一致（相當于事務開始時候進行了一次數據庫快照，事務內的查詢的是查詢開啟事務時刻的數據庫快照的數據），避免不可重復讀但可能出現幻讀（同一事務內多次查詢返回不同行數）。

-- ----------------------
-- 窗口1（事務A）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;-- 修改A賬戶余額并提交
UPDATE account SET balance = 800 WHERE name = 'A賬戶';
COMMIT;-- ----------------------
-- 窗口2（事務B）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;-- 第一次查詢
SELECT * FROM account;  -- 結果：A賬戶1000-- 此時事務A已提交...-- 第二次查詢（結果與第一次一致）
SELECT * FROM account;  -- 結果：A賬戶1000（可重復讀）-- 提交事務B后，才能看到A的修改
COMMIT;
SELECT * FROM account;  -- 結果：A賬戶800

這里需要強調下為什么會出現幻讀同一事務內多次查詢返回不同行數）。
雖然不可重復讀讀的是快照讀，但是使用update/insert/delete等時，是會先當前讀，也就是說的是已提交的數據，此刻的快照讀會更新為當前使用update/insert/delete等時數據庫的快照，所以再之后的普通讀select中的快照和最開始的快照的版本是不一樣的了，讀的數據也就不一樣了。幻讀例子如下：

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;-- 插入新記錄
INSERT INTO account(name, balance) VALUES ('C賬戶', 500);
COMMIT;

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;-- 第一次查詢（返回2條記錄）
SELECT COUNT(*) FROM account;  -- 此時事務A插入新記錄并提交...-- 第二次查詢（仍返回2條記錄）
SELECT COUNT(*) FROM account;  -- 執行更新操作后再次查詢（出現幻讀）
UPDATE account SET balance = balance+100 WHERE name = 'A賬戶';
SELECT COUNT(*) FROM account;  -- 返回3條記錄
COMMIT;

串行化（Serializable）：最高隔離級別，完全禁止并發問題，所有事務完全同步性能最低（按照一定的順序執行）。事務A插入數據，事務B在查詢時被阻塞，避免幻讀。

-- 事務A
-- ----------------------
-- 窗口1（事務A）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;-- 查詢當前數據
SELECT * FROM account;  -- 結果：A賬戶1000，B賬戶1000-- ----------------------
-- 窗口2（事務B）
-- ----------------------
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;-- 插入新數據（會被事務A阻塞，直到A提交或回滾）
INSERT INTO account (name, balance) VALUES ('C賬戶', 1000);-- 窗口1提交事務
COMMIT;-- 窗口2的插入操作繼續執行（此時事務A已提交）
-- 提交后，窗口1再次查詢會看到新數據（幻讀解決）

三、@Transactional注解

@Transactional注解簡介

@Transactional是Spring框架提供的聲明式事務管理注解，用于簡化數據庫事務操作。通過在方法或類上添加該注解，可以自動管理事務的開啟、提交、回滾等操作，無需手動編寫事務代碼。

基本用法

在Spring Boot項目中，需要在啟動類或配置類上添加@EnableTransactionManagement以啟用事務管理功能。隨后可以在服務層方法上使用@Transactional注解：

@Service
public class UserService {@Autowiredprivate UserRepository userRepository;@Transactionalpublic void createUser(User user) {userRepository.save(user);}
}

常用屬性配置

@Transactional提供多個屬性用于定制事務行為：

#使用注解時候默認配置如下
@Transactional(propagation = Propagation.REQUIRED,isolation = Isolation.DEFAULT,timeout = -1,readOnly = false,rollbackFor = {RuntimeException.class, Error.class}
)

自定義注解配置

@Transactional(propagation = Propagation.REQUIRED, --事務傳播行為isolation = Isolation.DEFAULT, --隔離級別，數據庫默認不可重讀timeout = 30, --定義超時時間，超過自動給回滾readOnly = false, --不只讀，可修改rollbackFor = {SQLException.class}, --遇到異常捕獲后必須回滾noRollbackFor = {NullPointerException.class} --遇到NullPointerException異常時不回滾事務
)
public void updateUser(User user) {// 業務邏輯
}

事務傳播行為

Spring定義了7種事務傳播行為，常用選項包括：

• REQUIRED：默認值，當前有事務則加入，沒有則新建
• REQUIRES_NEW：總是新建事務，暫停當前事務
• NESTED：在當前事務中嵌套子事務
• SUPPORTS：有事務則加入，沒有則以非事務方式執行
• NOT_SUPPORTED：以非事務方式執行，暫停當前事務
• MANDATORY：必須在事務中調用，否則拋出異常
• NEVER：不能在事務中調用，否則拋出異常

事務隔離級別

隔離級別控制事務間的可見性：

• DEFAULT：使用數據庫默認級別
• READ_UNCOMMITTED：讀未提交
• READ_COMMITTED：讀已提交
• REPEATABLE_READ：可重復讀
• SERIALIZABLE：串行化

異常處理與回滾

默認只在運行時異常和Error時回滾，可通過以下屬性調整：

• rollbackFor：指定觸發回滾的異常類型
• noRollbackFor：指定不觸發回滾的異常類型
• rollbackForClassName：通過類名指定回滾異常
• noRollbackForClassName：通過類名指定不回滾異常

性能優化建議

對于只讀操作，建議明確設置readOnly=true：

@Transactional(readOnly = true)
public User getUser(Long id) {return userRepository.findById(id);
}

避免在事務方法中進行遠程調用或耗時操作，防止事務長時間占用連接。

四、 事務不生效的可能原因

在很多面試題會問事務不生效的原因， @Transactional 是基于Spring AOP實現的事務切面，所以失效本質上可以歸因于AOP代理未生效或切面邏輯被阻斷。Spring通過 @EnableTransactionManagement 開啟事務支持，底層使用 TransactionInterceptor 攔截目標方法，生成代理對象（JDK動態代理或CGLIB代理）。只有通過代理對象調用方法時，事務切面才會生效；若直接調用目標對象（如 this.方法() ），會繞過代理，導致事務失效。

方法訪問權限非public

Spring事務代理要求目標方法必須是public，若定義為private/protected/default，代理無法攔截方法調用。

@Transactional  // 失效
private void saveData() {// 操作數據庫
}

自調用問題

同類中非事務方法調用事務方法，因直接調用this而非代理對象，導致攔截失效。

public class OrderService {public void createOrder() {this.saveOrder();  // 自調用，事務失效}@Transactionalpublic void saveOrder() {// 保存訂單}
}

異常被捕獲未拋出

spring默認僅對RuntimeException和Error回滾，若捕獲異常且未重新拋出，事務管理器無法感知異常。示例：

@Transactional
public void update() {try {jdbcTemplate.update("...");} catch (DataAccessException e) {// 捕獲后未拋出，事務不會回滾}
}

通過@Transactional注解指定需回滾的異常：

@Transactional(rollbackFor = IOException.class)

將受檢異常轉換為事務管理器可識別的類型：

catch (IOException e) {throw new RuntimeException("Wrapped exception", e);
}

數據庫引擎不支持事務

如MySQL的MyISAM引擎不支持事務，需改用InnoDB。配置示例：

CREATE TABLE test (id INT PRIMARY KEY
) ENGINE=InnoDB;  // 必須為InnoDB

未啟用事務管理

Spring Boot需配置@EnableTransactionManagement（默認自動開啟），傳統項目遺漏此注解會導致事務失效。示例缺失：

@SpringBootApplication
// 若手動配置需添加@EnableTransactionManagement
public class App {public static void main(String[] args) {SpringApplication.run(App.class, args);}
}

特殊場景：final/static方法

代理無法增強final/static方法，導致事務失效。示例：

@Transactional
public final void process() {  // final方法失效// 業務邏輯
}

五、分布式事務考慮

對于跨服務的事務操作，@Transactional只能管理本地事務。分布式場景可考慮：

1. Seata框架
2. 消息隊列最終一致性
3. TCC模式
4. SAGA模式

---

總結

在開發過程中遇到過在同一條件下查詢出不同的數據結果，最后發現是對事務的理解使用欠缺導致。這個問題在開發過程中通過還挺常見的，不僅僅是在面對事務的時候加個@Transactional注解就完事了。
本文梳理了數據庫事務的基本概念和隔離級別，同時對spring中的事務框架做了簡單的介紹，覺得有用請點下贊吧。