在數(shù)據(jù)庫開發(fā)中，事務(wù)是保障數(shù)據(jù)安全的核心機制。無論是電商下單、銀行轉(zhuǎn)賬還是火車票售票，一旦涉及多步數(shù)據(jù)操作，若不加控制，就會出現(xiàn)數(shù)據(jù)不一致、超賣、重復(fù)扣款等嚴重問題。本文將從實際問題出發(fā)，系統(tǒng)拆解 MySQL 事務(wù)的核心概念、ACID 特性、隔離級別、底層實現(xiàn)（MVCC）及實戰(zhàn)操作，幫你徹底搞懂事務(wù)的底層邏輯與使用規(guī)范。

一、為什么需要事務(wù)？從一個超賣案例說起

先看經(jīng)典的火車票售票系統(tǒng)超賣問題，這是無事務(wù)場景下的典型數(shù)據(jù)錯亂案例。

1.1 場景模擬

有一張火車票表tickets，僅剩 1 張西安 <-> 蘭州的車票：

此時客戶端 A和客戶端 B同時發(fā)起購票請求，偽代碼邏輯如下：

// 客戶端A
if (nums > 0) { // 檢查有票
    賣票();
    update tickets set nums = nums - 1; // 更新票數(shù)
}
// 客戶端B
if (nums > 0) { // 同時檢查有票（此時A還沒更新數(shù)據(jù)庫）
    賣票();
    update tickets set nums = nums - 1; // 再次更新票數(shù)
}

1.2 問題結(jié)果

• 客戶端 A 檢查到票數(shù) = 1，準(zhǔn)備賣票，但還沒執(zhí)行 update 更新數(shù)據(jù)庫；
• 客戶端 B 同時檢查，發(fā)現(xiàn)票數(shù)仍 = 1，也執(zhí)行賣票；
• 最終 A、B 都執(zhí)行update，票數(shù)從 1 變成 - 1，同一張票被賣了兩次，出現(xiàn)超賣。

1.3 解決方案：事務(wù)的四大核心訴求

要解決上述問題，買票操作必須滿足 4 個核心屬性，這正是事務(wù)的設(shè)計初衷：

1. 原子性：買票的檢查 + 更新操作，要么全部成功，要么全部失敗，不能只執(zhí)行一半；
2. 一致性：買票前后，數(shù)據(jù)庫票數(shù)始終合法（不能為負、不能超賣）；
3. 隔離性：多個客戶端買票時，操作互相隔離，互不干擾；
4. 持久性：買票成功后，即使服務(wù)器宕機，數(shù)據(jù)也不會丟失。

二、事務(wù)的基本概念與核心特性（ACID）

2.1 什么是事務(wù)？

事務(wù)是一組邏輯相關(guān)的 DML 語句集合（增刪改查），這些語句在邏輯上是一個整體，要么全部執(zhí)行成功，要么全部執(zhí)行失敗，不存在 “部分成功、部分失敗” 的中間狀態(tài)。

簡單說，事務(wù)就是 “要么全做，要么全不做” 的不可分割工作單元。例如：

• 銀行轉(zhuǎn)賬：A 扣錢、B 加錢，必須同時成功或同時失?。?/li>
• 電商下單：扣庫存、生成訂單、扣余額，必須作為一個整體執(zhí)行。

2.2 事務(wù)的四大核心特性（ACID）

事務(wù)必須滿足原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability） 四大特性，簡稱 ACID，這是事務(wù)的核心準(zhǔn)則。

1. 原子性（Atomicity）：不可分割，要么全成要么全敗

• 定義：一個事務(wù)中的所有操作，是一個不可分割的原子，要么全部執(zhí)行成功，要么全部回滾到事務(wù)開始前的狀態(tài)，不會停留在中間環(huán)節(jié)。
• 底層保障：通過Undo Log（回滾日志） 實現(xiàn)。事務(wù)執(zhí)行前，會把數(shù)據(jù)修改前的狀態(tài)記錄到 Undo Log；若事務(wù)執(zhí)行失敗或崩潰，MySQL 會利用 Undo Log 將數(shù)據(jù)恢復(fù)到事務(wù)開始前的狀態(tài)。
• 案例：轉(zhuǎn)賬時，A 扣了 100 元但 B 沒加錢，事務(wù)會回滾，A 的 100 元自動恢復(fù)，避免數(shù)據(jù)丟失。

2. 一致性（Consistency）：數(shù)據(jù)合法，狀態(tài)一致

定義：事務(wù)執(zhí)行前后，數(shù)據(jù)庫的完整性約束不被破壞，數(shù)據(jù)從一個合法狀態(tài)轉(zhuǎn)移到另一個合法狀態(tài)，不會出現(xiàn)非法數(shù)據(jù)。

核心要點：

• 數(shù)據(jù)必須符合預(yù)設(shè)規(guī)則（主鍵唯一、外鍵關(guān)聯(lián)、非空、余額非負等）；
• 一致性由原子性、隔離性、持久性共同保障，同時依賴業(yè)務(wù)邏輯（如余額不能為負）。

案例：火車票售票，無論賣多少次，票數(shù)不能為負；轉(zhuǎn)賬前后，A 和 B 的總余額始終不變。

3. 隔離性（Isolation）：并發(fā)隔離，互不干擾

• 定義：多個事務(wù)并發(fā)執(zhí)行時，互相隔離、互不干擾，一個事務(wù)的操作在未提交前，對其他事務(wù)不可見，避免并發(fā)導(dǎo)致的數(shù)據(jù)錯亂。
• 核心作用：解決高并發(fā)下的臟讀、不可重復(fù)讀、幻讀問題（后文詳細講解）。
• 底層保障：通過鎖機制和MVCC（多版本并發(fā)控制） 實現(xiàn)，不同隔離級別對應(yīng)不同的鎖策略。

4. 持久性（Durability）：提交即永久，宕機不丟失

• 定義：事務(wù)一旦提交（COMMIT），對數(shù)據(jù)的修改就是永久生效的，即使服務(wù)器斷電、宕機，數(shù)據(jù)也不會丟失。
• 底層保障：通過Redo Log（重做日志） 實現(xiàn)。事務(wù)提交時，先把修改記錄寫入 Redo Log，再異步刷到磁盤；若崩潰，重啟后通過 Redo Log 恢復(fù)數(shù)據(jù)。

2.3 事務(wù)的引擎支持：僅 InnoDB 支持事務(wù)

MySQL 中，只有 InnoDB 引擎支持事務(wù)，MyISAM、MEMORY 等引擎不支持事務(wù)，這也是 InnoDB 成為 MySQL 默認引擎的核心原因。

查看數(shù)據(jù)庫引擎及事務(wù)支持情況：

-- 查看所有引擎
show engines;

-- 行格式顯示，重點看Transactions字段（YES=支持，NO=不支持）
show engines \G;

關(guān)鍵結(jié)果：

• InnoDB：Transactions=YES（支持事務(wù)、行鎖、外鍵）；
• MyISAM：Transactions=NO（不支持事務(wù)）。

三、事務(wù)的提交方式與基礎(chǔ)操作

3.1 事務(wù)的兩種提交方式

MySQL 事務(wù)默認自動提交，也可手動控制提交 / 回滾，兩種方式：

1. 自動提交（默認）

規(guī)則：每條 SQL 語句都是一個獨立事務(wù)，執(zhí)行后自動提交，無法回滾；

查看狀態(tài)：

show variables like 'autocommit'; -- 默認ON（開啟）

關(guān)閉自動提交：

set autocommit=0; -- OFF（關(guān)閉），需手動commit/rollback

2. 手動提交（顯式事務(wù)）

• 規(guī)則：通過BEGIN/START TRANSACTION顯式開啟事務(wù)，執(zhí)行 SQL 后，手動 COMMIT 提交（永久生效）或 ROLLBACK 回滾（撤銷操作）。
• 核心命令：

-- 1. 開啟事務(wù)（二選一，推薦BEGIN）
BEGIN;
START TRANSACTION;

-- 2. 執(zhí)行DML操作（增刪改）
insert into account values (1, '張三', 100);
update account set blance=200 where id=1;

-- 3. 提交事務(wù)（永久生效，不可回滾）
COMMIT;

-- 4. 回滾事務(wù)（撤銷所有未提交操作，恢復(fù)到事務(wù)開始前）
ROLLBACK;

3.2 事務(wù)保存點（SAVEPOINT）：部分回滾

事務(wù)支持保存點，可在事務(wù)中設(shè)置多個保存點，回滾時可指定回滾到某個保存點，無需回滾整個事務(wù)。

示例：保存點的創(chuàng)建與回滾

-- 1. 開啟事務(wù)
BEGIN;

-- 2. 創(chuàng)建保存點save1
SAVEPOINT save1;
insert into account values (1, '張三', 100);

-- 3. 創(chuàng)建保存點save2
SAVEPOINT save2;
insert into account values (2, '李四', 10000);

-- 4. 回滾到save2（僅撤銷李四的插入，張三的數(shù)據(jù)保留）
ROLLBACK TO save2;

-- 5. 提交事務(wù)（最終僅張三的數(shù)據(jù)生效）
COMMIT;

3.3 事務(wù)操作核心結(jié)論

1. 執(zhí)行BEGIN/START TRANSACTION后，事務(wù)必須通過COMMIT提交才會持久化，與autocommit無關(guān)；
2. 事務(wù)未提交時，客戶端崩潰，MySQL 會自動回滾所有未提交操作；
3. 事務(wù)提交后，客戶端崩潰，數(shù)據(jù)不會丟失，已持久化到數(shù)據(jù)庫；
4. 單條 SQL 在autocommit=ON時，自動封裝為獨立事務(wù)，執(zhí)行后永久生效。

四、事務(wù)隔離級別：平衡一致性與并發(fā)性能

4.1 并發(fā)事務(wù)的三大問題

多個事務(wù)并發(fā)執(zhí)行時，若隔離性不足，會出現(xiàn)臟讀、不可重復(fù)讀、幻讀三大問題，嚴重影響數(shù)據(jù)一致性。

1. 臟讀（Dirty Read）

• 定義：一個事務(wù)讀取到另一個事務(wù)未提交的修改數(shù)據(jù)，后續(xù)該事務(wù)回滾，導(dǎo)致讀取的數(shù)據(jù)無效。
• 案例：
  • 事務(wù) A：更新張三余額為 123，未提交；
  • 事務(wù) B：讀取張三余額 = 123（臟讀）；
  • 事務(wù) A：回滾，張三余額恢復(fù)為 100；
  • 結(jié)果：事務(wù) B 讀取到無效數(shù)據(jù)。

2. 不可重復(fù)讀（Non-Repeatable Read）

• 定義：同一個事務(wù)內(nèi)，多次讀取同一數(shù)據(jù)，結(jié)果不一致（因其他事務(wù)中途提交修改）。
• 案例：
  • 事務(wù) B：第一次讀取張三余額 = 123；
  • 事務(wù) A：更新張三余額為 321，提交；
  • 事務(wù) B：第二次讀取張三余額 = 321；
  • 結(jié)果：同一事務(wù)內(nèi)，兩次讀取結(jié)果不同。

3. 幻讀（Phantom Read）

• 定義：同一個事務(wù)內(nèi)，多次查詢同一條件的數(shù)據(jù)，記錄數(shù)不一致（因其他事務(wù)中途插入 / 刪除數(shù)據(jù)）。
• 案例：
  • 事務(wù) B：第一次查詢 account 表，有 2 條記錄；
  • 事務(wù) A：插入一條新記錄（王五），提交；
  • 事務(wù) B：第二次查詢 account 表，有 3 條記錄；
  • 結(jié)果：如同 “幻覺”，記錄數(shù)憑空增加。

4.2 MySQL 的四大隔離級別

SQL 標(biāo)準(zhǔn)定義了 4 種隔離級別，隔離級別越高，一致性越強，并發(fā)性能越低；MySQL InnoDB 默認采用可重復(fù)讀（REPEATABLE READ）。

隔離級別對比表

1. 讀未提交（READ UNCOMMITTED）

• 規(guī)則：所有事務(wù)可讀取其他事務(wù)未提交的修改，無任何隔離；
• 問題：臟讀、不可重復(fù)讀、幻讀全部存在；
• 性能：最高（幾乎不加鎖）；
• 使用：生產(chǎn)環(huán)境絕對禁止，僅用于測試。

2. 讀已提交（READ COMMITTED，RC）

• 規(guī)則：事務(wù)只能讀取其他事務(wù)已提交的修改，看不到未提交數(shù)據(jù)；
• 解決：臟讀；
• 殘留：不可重復(fù)讀、幻讀；
• 特點：每次SELECT都會生成新快照（Read View），能看到最新提交數(shù)據(jù)。

3. 可重復(fù)讀（REPEATABLE READ，RR，MySQL 默認）

• 規(guī)則：同一個事務(wù)內(nèi)，多次讀取同一數(shù)據(jù)，結(jié)果始終一致；
• 解決：臟讀、不可重復(fù)讀；
• 殘留：幻讀（InnoDB 通過 Next-Key 鎖（間隙鎖 + 行鎖）解決幻讀）；
• 特點：事務(wù)內(nèi)第一次SELECT生成快照（Read View），后續(xù)復(fù)用，保證可重復(fù)讀。

4. 串行化（SERIALIZABLE）

• 規(guī)則：事務(wù)串行執(zhí)行（排隊執(zhí)行），一個事務(wù)執(zhí)行完，下一個才開始；
• 解決：臟讀、不可重復(fù)讀、幻讀全部解決；
• 性能：最低（全表鎖 / 行鎖，并發(fā)完全阻塞）；
• 使用：僅用于金融核心、數(shù)據(jù)強一致場景，生產(chǎn)環(huán)境極少用。

4.3 隔離級別查看與設(shè)置

1. 查看隔離級別

-- 查看全局隔離級別
SELECT @@global.tx_isolation;

-- 查看當(dāng)前會話隔離級別
SELECT @@session.tx_isolation;

-- 簡寫（默認同會話）
SELECT @@tx_isolation;

2. 設(shè)置隔離級別

-- 設(shè)置當(dāng)前會話隔離級別（僅當(dāng)前連接生效）
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 設(shè)置全局隔離級別（新連接生效，需重啟客戶端）
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

五、隔離級別底層實現(xiàn)：MVCC（多版本并發(fā)控制）

5.1 什么是 MVCC？

MVCC（Multi-Version Concurrency Control，多版本并發(fā)控制）是 InnoDB 實現(xiàn)讀已提交（RC）、可重復(fù)讀（RR） 隔離級別的核心機制，核心目標(biāo)是讀寫不阻塞、讀不加鎖、提升并發(fā)性能。

簡單說，MVCC 的核心是 **“數(shù)據(jù)多版本”**：數(shù)據(jù)修改時，不直接覆蓋原數(shù)據(jù)，而是生成新版本，保留歷史版本；讀操作時，讀取當(dāng)前事務(wù)可見的歷史版本，無需加鎖。

5.2 MVCC 的三大核心組件

1. 隱藏字段（每行數(shù)據(jù)自帶）

InnoDB 每行數(shù)據(jù)包含 3 個隱藏字段，用于版本管理：

• DB_TRX_ID：6 字節(jié)，最近修改該記錄的事務(wù) ID（插入 / 更新時賦值）；
• DB_ROLL_PTR：7 字節(jié)，回滾指針，指向該記錄的上一個版本（Undo Log 中的歷史數(shù)據(jù)）；
• DB_ROW_ID：6 字節(jié)，隱式主鍵（無主鍵時自動生成）。

2. Undo Log（回滾日志）

• 存儲數(shù)據(jù)的歷史版本，數(shù)據(jù)更新時，舊版本寫入 Undo Log，通過DB_ROLL_PTR形成版本鏈；
• 作用：事務(wù)回滾時恢復(fù)數(shù)據(jù)、MVCC 讀取歷史版本。

3. Read View（讀視圖）

• 事務(wù)快照讀（普通 SELECT）時生成的可見性判斷規(guī)則，記錄當(dāng)前系統(tǒng)活躍事務(wù) ID 列表，用于判斷當(dāng)前事務(wù)能讀取哪個版本的數(shù)據(jù)；
• 核心字段：
  • m_ids：活躍事務(wù) ID 列表；
  • m_up_limit_id：活躍事務(wù)最小 ID；
  • m_low_limit_id：下一個未分配事務(wù) ID；
  • m_creator_trx_id：當(dāng)前事務(wù) ID。

5.3 快照讀 vs 當(dāng)前讀

MVCC 中，讀操作分兩種，行為完全不同：

1. 快照讀（普通 SELECT）

• SQL：SELECT * FROM account WHERE id=1;；
• 規(guī)則：讀取歷史版本數(shù)據(jù)，不加鎖，依賴 MVCC；
• 場景：RC、RR 隔離級別下的普通查詢。

2. 當(dāng)前讀（加鎖 / 修改操作）

• SQL：SELECT ... FOR UPDATE、UPDATE、DELETE、INSERT；
• 規(guī)則：讀取最新版本數(shù)據(jù)，加鎖（行鎖 / 間隙鎖），防止并發(fā)修改；
• 場景：數(shù)據(jù)更新、加鎖查詢。

5.4 RC vs RR：Read View 生成時機的差異

MVCC 中，RC 和 RR 隔離級別的核心區(qū)別是Read View 生成時機：

• RC（讀已提交）：每次快照讀（SELECT）都生成新 Read View，能看到其他事務(wù)已提交的修改，因此存在不可重復(fù)讀；
• RR（可重復(fù)讀）：事務(wù)內(nèi)第一次快照讀生成 Read View，后續(xù)復(fù)用，看不到其他事務(wù)提交的修改，因此解決不可重復(fù)讀。

六、總結(jié)：事務(wù)核心要點與實戰(zhàn)建議

6.1 核心要點回顧

1. 事務(wù)定義：一組 DML 語句的整體，要么全成要么全敗，保障數(shù)據(jù)一致性；
2. ACID 特性：原子性（Undo Log）、一致性（業(yè)務(wù) + ACID）、隔離性（鎖 + MVCC）、持久性（Redo Log）；
3. 引擎支持：僅InnoDB支持事務(wù)，MyISAM 不支持；
4. 隔離級別：MySQL 默認RR（可重復(fù)讀），平衡一致性與并發(fā)；
5. MVCC：InnoDB 實現(xiàn) RC/RR 的核心，讀寫不阻塞、讀不加鎖，通過隱藏字段、Undo Log、Read View 實現(xiàn)。

6.2 實戰(zhàn)使用建議

1. 優(yōu)先使用 InnoDB 引擎：所有需事務(wù)的表，引擎設(shè)為 InnoDB；
2. 默認隔離級別用 RR：無需特殊場景，保持 MySQL 默認 RR，兼顧安全與性能；
3. 短事務(wù)優(yōu)先：事務(wù)內(nèi)僅包含必要操作，避免長事務(wù)（易鎖超時、死鎖）；
4. 合理使用保存點：復(fù)雜事務(wù)中，用 SAVEPOINT 實現(xiàn)部分回滾；
5. 避免臟寫：更新數(shù)據(jù)時加索引條件，用行鎖避免表鎖，減少并發(fā)沖突。

以上就是系統(tǒng)講解MySQL數(shù)據(jù)庫中事務(wù)的核心機制與應(yīng)用實踐的詳細內(nèi)容，更多關(guān)于MySQL數(shù)據(jù)庫事務(wù)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論