本篇文章給大家帶來了關于mysql的相關知識，其中主要介紹了mysql的事務acid特性和mysql事務控制流程的語法，并介紹事務并發處理中可能出現的異常情況，比如臟讀、幻讀、不可重復讀等等，最后介紹事務隔離級別，希望對大家有幫助。

詳細解析MySQL事務

推薦學習：mysql

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

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

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

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

ACID 特性

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

之前的文章中我們提到過，MySQL 5.5 之后，默認的存儲引擎從 MyISAM 替換成了 InnoDB，這其中的一個重要原因就是因為 InnoDB 支持事務，我們用 SHOW ENGINES 來看一下 MySQL 中對各種存儲引擎的描述。
詳細解析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;

第二種方式可以查看全局和當前會話的隔離級別。
詳細解析MySQL事務
設置隔離級別的命令為

# 將當前會話的隔離級別設為讀未提交 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;  # 將全局的隔離級別設為讀未提交 SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;