本篇文章給大家帶來了關於的相關知識，其中主要介紹了MySQL的事務ACID特性和MySQL事務控制流程的語法，並介紹事務並行處理中可能出現的異常情況，比如髒讀、幻讀、不可重複讀等等，最後介紹事務隔離級別，希望對大家有幫助。

推薦學習：

在實際業務場景中，如何保證操作的完整性是一個重要的議題，依次執行一系列邏輯強關聯的操作，如果在中途發生了錯誤，就很有可能導致資料的錯亂。

設想一下在 ATM 取錢的場景，當我們取出一千元的時候，ATM 會在清點完成後一次性吐出一千元，而不是分十次每次吐出一百元，這就是為了保證操作的完整性，要麼完整的取走一千元，扣除餘額，要麼一分錢都沒有取走，餘額不變，而不會出現中途機器故障導致資料不一致的情況。這樣的一次完整操作叫做事務 transaction，一個事務中的所有操作要麼全部成功執行，要麼完全不執行。

本文將會介紹 MySQL 的事務 ACID 特性和 MySQL 事務控制流程的語法，並介紹事務並行處理中可能出現的異常情況，比如髒讀、幻讀、不可重複讀等等，最後介紹事務隔離級別。

關於實現事務隔離性的鎖和 MVCC，將會在之後的文章進行介紹。

ACID 特性

事務處理是一種對必須整批執行的 MySQL 操作的管理機制，在事務過程中，除非整批操作全部正確執行，否則中間的任何一個操作出錯，都會回滾 (Rollback) 到最初的安全狀態以確保不會對系統資料造成錯誤的改動。

之前的文章中我們提到過，MySQL 5.5 之後，預設的儲存引擎從 MyISAM 替換成了 InnoDB，這其中的一個重要原因就是因為 InnoDB 支援事務，我們用 SHOW ENGINES 來看一下 MySQL 中對各種儲存引擎的描述。
在這裡插入圖片描述
事務最重要的四個特性通常被稱為 ACID 特性
A - Atomicity 原子性: 一個事務是一個不可分割的最小單位，事務中的所有操作要麼全部成功，要麼全部失敗，沒有中間狀態。原子性主要是通過事務紀錄檔中的回滾紀錄檔(undo log)來實現的，當事務對資料庫進行修改時，InnoDB 會根據操作生成相反操作的 undo log，比如說對 insert 操作，會生成 delete 記錄，如果事務執行失敗或者呼叫了 rollback，就會根據 undo log 的內容恢復到執行之前的狀態。

C - Consistency 一致性: 事務執行之前和執行之後資料都是合法的一致性狀態，即使發生了異常，也不會因為異常引而破壞資料庫的完整性約束，比如唯一性約束等。

I - Isolation 隔離性: 每個事務是彼此獨立的，不會受到其他事務的執行影響，事務在提交之前對其他事務不可見。隔離性通過事務的隔離級別來定義，並用鎖機制來保證寫操作的隔離性，用 MVCC 來保證讀操作的隔離性，將在下文詳細介紹。

D - Durability 永續性: 事務提交之後對資料的修改是永續性的，即使資料庫宕機也不會丟失，通過事務紀錄檔中的重做紀錄檔(redo log)來保證。事務修改之前，會先把變更資訊預寫到 redo log 中，如果資料庫宕機，恢復後會讀取 redo log 中的記錄來恢復資料。

事務控制語法

MySQL 事務控制有幾個重要節點，分別是事務的開啟，提交，回滾和儲存點。

開啟事務代表事務開始執行，語句為 START TRANSACTION 或者 BEGIN，提交事務代表將事務中的所有更新都寫到磁碟的物理資料庫，事務正常執行結束，語句為 COMMIT，如果發生異常需要回滾，語句為 ROLLBACK。要注意的是，一旦事務已經提交，就不能回滾了，因此，在程式碼執行過程中捕獲到異常的時候需要直接執行 rollback 而不是 commit。

比如 A 向 B 轉賬 100 元的事務：

// 正常執行，提交
BEGIN; # 開啟事務
UPDATE account_balance SET balance = balance - 100.00 WHERE account_name = 'A';
UPDATE account_balance SET balance = balance + 100.00 WHERE account_name = 'B';
COMMIT; # 提交事務

// 發生異常，回滾
BEGIN; # 開啟事務
UPDATE account_balance SET balance = balance - 100.00 WHERE account_name = 'A';
UPDATE account_balance SET balance = balance + 100.00 WHERE account_name = 'B';
ROLLBACK; # 事務回滾

在複雜場景中，有時我們不需要全盤迴滾整個操作，而是分批執行，回滾到某個節點就好了，相當於是在一個大事務下巢狀了若干個子事務，在 MySQL 中可以使用保留點 SAVEPOINT 來實現。

BEGIN;
insert into user_tbl (id) values (1) ;
insert into user_tbl (id) values (2) ;
ROLLBACK;   # 1,2 都沒有寫入
BEGIN;
insert into user_tbl (id) values (1) ;
SAVEPOINT s1;
insert into user_tbl (id) values (2) ;
ROLLBACK TO s1;   # 回滾到保留點 s1, 因此 1 成功寫入，2 被回滾, 最終結果為 1
RELEASE SAVEPOINT s1; # 釋放保留點

順便提一下，事務有隱式事務（自動提交）和顯示事務（必須手動提交）兩種，MySQL 預設為隱式事務，會進行自動提交，通過 autocommit 引數來控制。

# 檢視變數
SHOW VARIABLES LIKE 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
# 開啟自動提交（預設）
SET autocommit = 1;
# 關閉自動提交
SET autocommit = 0;

在自動提交狀態下，如果沒有顯示的開啟事務，那每一條語句都是一個事務，系統會自動對每一條 sql 執行 commit 操作。使用 BEGIN 或 START TRANSACTION 開啟一個事務之後，自動提交將保持禁用狀態，直到使用 COMMIT 或 ROLLBACK 結束事務之後，自動提交模式會恢復到之前的狀態。

關於事務還有另一個引數 completion_type，預設取值為 0 (NO_CHAIN)

# 檢視變數
SHOW VARIABLES LIKE 'completion_type';
+-----------------+----------+
| Variable_name   |   Value  |
+-----------------+----------+
| completion_type | NO_CHAIN |
+-----------------+----------+

completion_type = 0: 預設值，執行 commit 後不會自動開啟新的事務。
completion_type = 1: 執行 commit 時，相當於執行 COMMIT AND CHAIN，自動開啟一個相同隔離級別的事務。
completion_type = 2: 執行 commit 時，相當於執行 COMMIT AND RELEASE，提交事務後自動斷開伺服器連線。

事務並行異常

在實際產線環境下，可能會存在大規模並行請求的情況，如果沒有妥善的設定事務的隔離級別，就可能導致一些異常情況的出現，最常見的幾種異常為髒讀(Dirty Read)、幻讀(Phantom Read)和不可重複讀(Unrepeatable Read)。

髒讀

髒讀指一個事務存取到了另一個事務未提交的資料，如下過程:

假設 a 的值為 1，事務 2 把 a 改為 2，此時事務還未提交
在這個時候，事務 1 讀取 a，讀得 a 的值為 2，事務 1 讀取完成
結果事務 2 回滾了對 a 的修改（或者是未 commit），於是 a 的值變回 1
這就導致事實上 a 的值為 1，但是事務 1 取得的結果為 2，所以事務 1 讀到了髒資料，發生髒讀

不可重複讀

不可重複讀指一個事務多次讀取同一資料的過程中，資料值內容發生了改變，導致沒有辦法讀到相同的值，描述的是針對同一條資料 update/delete 的現象，如下過程：

事務 1 讀取 a，此時 a = 1
此時事務 2 將 a 修改為 2，併成功提交，改動生效
事務 1 又一次讀取 a，此時 a = 2
事務 1 在同一個事務裡面兩次讀取同一個值，資料值內容卻發生了改變，發生不可重複讀

幻讀

幻讀指一個事務多次讀取同一資料的過程中，全域性資料（如資料行數）發生了改變，彷彿產生了幻覺，描述的是針對全表 insert/delete 的現象，如下過程：

事務 1 第一次讀取數量，得到 10 條資料
此時事務 2 插入了一條資料併成功提交，改動生效，資料變成 11 條
事務 1 再次讀取數量，得到 11 條資料，對事務 1 而言莫名其妙的多了一條，好像產生幻覺了一樣，發生幻讀

或者是另一種場景，比如對於有唯一性約束的欄位（如 id），發生如下過程：

事務 1 要插入 id = 5 的記錄，先查詢資料庫，發現不存在 id = 5 的資料，可以正常插入。
這時候事務 2 插入了一條資料 id = 5。
事務 1 插入 id = 5 時，發現報錯唯一性衝突，對事務 1 來講就好像見了鬼了，我剛剛明明檢查過沒有，怎麼這時候又有了。

事務隔離級別

序列化的事務處理方式當然是最安全的，但是序列無法滿足資料庫高並行存取的需求，作為妥協，有時不得不降低資料庫的隔離標準來換取事務的並行能力，通過在可控的範圍內犧牲正確性來換取效率的提升，這種權衡通過事務的隔離級別來實現。

資料庫有 4 種事務隔離級別，由低到高依次為 讀未提交 Read Uncommitted 、讀已提交 Read Committed 、可重複讀 Repeatable Read 、序列化 Serializable 。

讀未提交 Read Uncommitted
允許讀取未提交的內容，這種級別下的查詢不會加鎖，因此髒讀、不可重複讀、幻讀都有可能發生。
讀已提交 Read Committed
只允許讀取已提交的內容，這種級別下的查詢不會發生髒讀，因為髒資料屬於未提交的資料，所以不會被讀取，但是依然有可能發生不可重複讀和幻讀。
可重複讀 Repeatable Read （MySQL 的預設隔離級別）
使用行級鎖來保證一個事務在相同查詢條件下兩次查詢得到的資料結果一致，可以避免髒讀和不可重複讀，但是沒有辦法避免幻讀。
需要特殊注意的是，Innodb 在 Repeatable Read 下通過 MVCC 提供了穩定的檢視，因此 Innodb 的 RR 隔離級別下是不會出現上述幻讀異常中的第一個場景的，但第二個場景還是會出現。
序列化 Serializable
使用表級鎖來保證所有事務的序列化，可以防止所有的異常情況，但是犧牲了系統的並行性。

檢視隔離級別的命令為

SHOW VARIABLES LIKE 'transaction_isolation';
# 或者
SELECT @@global.tx_isolation, @@tx_isolation;

第二種方式可以檢視全域性和當前對談的隔離級別。
在這裡插入圖片描述
設定隔離級別的命令為

# 將當前對談的隔離級別設為讀未提交
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 
# 將全域性的隔離級別設為讀未提交
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

結語

本文簡單介紹了 MySQL 事務的語法和 ACID 特性，以及事務並行處理中可能出現的異常情況和為了防止這些異常而設計的事務隔離級別。有興趣的朋友可以嘗試在兩個不同的 MySQL 使用者端來模擬四種隔離級別下三種異常的發生情況，在之後的文章中，會繼續深入探討 MySQL 是如何實現隔離級別的。

推薦學習：

以上就是詳細解析MySQL事務的詳細內容，更多請關注TW511.COM其它相關文章！