MySQL事務的示例分析

這篇文章將為大家詳細講解有關MySQL事務的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

ACID 特性

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

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

事務最重要的四個特性通常被稱為 ACID 特性
A - Atomicity 原子性: 一個事務是一個不可分割的最小單位，事務中的所有操作要么全部成功，要么全部失敗，沒有中間狀態(tài)。原子性主要是通過事務日志中的回滾日志(undo log)來實現(xiàn)的，當事務對數(shù)據(jù)庫進行修改時，InnoDB 會根據(jù)操作生成相反操作的 undo log，比如說對 insert 操作，會生成 delete 記錄，如果事務執(zhí)行失敗或者調用了 rollback，就會根據(jù) undo log 的內容恢復到執(zhí)行之前的狀態(tài)。

C - Consistency 一致性: 事務執(zhí)行之前和執(zhí)行之后數(shù)據(jù)都是合法的一致性狀態(tài)，即使發(fā)生了異常，也不會因為異常引而破壞數(shù)據(jù)庫的完整性約束，比如唯一性約束等。

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

D - Durability 持久性: 事務提交之后對數(shù)據(jù)的修改是持久性的，即使數(shù)據(jù)庫宕機也不會丟失，通過事務日志中的重做日志(redo log)來保證。事務修改之前，會先把變更信息預寫到 redo log 中，如果數(shù)據(jù)庫宕機，恢復后會讀取 redo log 中的記錄來恢復數(shù)據(jù)。

事務控制語法

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

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

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

// 正常執(zhí)行，提交
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; # 提交事務

// 發(fā)生異常，回滾
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; # 事務回滾

在復雜場景中，有時我們不需要全盤回滾整個操作，而是分批執(zhí)行，回滾到某個節(jié)點就好了，相當于是在一個大事務下嵌套了若干個子事務，在 MySQL 中可以使用保留點 SAVEPOINT 來實現(xiàn)。

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 參數(shù)來控制。

# 查看變量
SHOW VARIABLES LIKE 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
# 開啟自動提交（默認）
SET autocommit = 1;
# 關閉自動提交
SET autocommit = 0;

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

關于事務還有另一個參數(shù) completion_type，默認取值為 0 (NO_CHAIN)

# 查看變量
SHOW VARIABLES LIKE 'completion_type';
+-----------------+----------+
| Variable_name   |   Value  |
+-----------------+----------+
| completion_type | NO_CHAIN |
+-----------------+----------+

completion_type = 0: 默認值，執(zhí)行 commit 后不會自動開啟新的事務。
completion_type = 1: 執(zhí)行 commit 時，相當于執(zhí)行 COMMIT AND CHAIN，自動開啟一個相同隔離級別的事務。
completion_type = 2: 執(zhí)行 commit 時，相當于執(zhí)行 COMMIT AND RELEASE，提交事務后自動斷開服務器連接。

事務并發(fā)異常

在實際產(chǎn)線環(huán)境下，可能會存在大規(guī)模并發(fā)請求的情況，如果沒有妥善的設置事務的隔離級別，就可能導致一些異常情況的出現(xiàn)，最常見的幾種異常為臟讀(Dirty Read)、幻讀(Phantom Read)和不可重復讀(Unrepeatable Read)。

臟讀

臟讀指一個事務訪問到了另一個事務未提交的數(shù)據(jù)，如下過程:

1. 假設 a 的值為 1，事務 2 把 a 改為 2，此時事務還未提交

2. 在這個時候，事務 1 讀取 a，讀得 a 的值為 2，事務 1 讀取完成

3. 結果事務 2 回滾了對 a 的修改（或者是未 commit），于是 a 的值變回 1

4. 這就導致事實上 a 的值為 1，但是事務 1 取得的結果為 2，所以事務 1 讀到了臟數(shù)據(jù)，發(fā)生臟讀
   

不可重復讀

不可重復讀指一個事務多次讀取同一數(shù)據(jù)的過程中，數(shù)據(jù)值 內容 發(fā)生了改變，導致沒有辦法讀到相同的值，描述的是針對同一條數(shù)據(jù) update/delete 的現(xiàn)象，如下過程：

1. 事務 1 讀取 a，此時 a = 1

2. 此時事務 2 將 a 修改為 2，并成功提交，改動生效

3. 事務 1 又一次讀取 a，此時 a = 2

4. 事務 1 在同一個事務里面兩次讀取同一個值，數(shù)據(jù)值內容卻發(fā)生了改變，發(fā)生不可重復讀
   

幻讀

幻讀指一個事務多次讀取同一數(shù)據(jù)的過程中，全局數(shù)據(jù)（如數(shù)據(jù)行數(shù)）發(fā)生了改變，仿佛產(chǎn)生了幻覺，描述的是針對全表 insert/delete 的現(xiàn)象，如下過程：

1. 事務 1 第一次讀取數(shù)量，得到 10 條數(shù)據(jù)

2. 此時事務 2 插入了一條數(shù)據(jù)并成功提交，改動生效，數(shù)據(jù)變成 11 條

3. 事務 1 再次讀取數(shù)量，得到 11 條數(shù)據(jù)，對事務 1 而言莫名其妙的多了一條，好像產(chǎn)生幻覺了一樣，發(fā)生幻讀
   

或者是另一種場景，比如對于有唯一性約束的字段（如 id），發(fā)生如下過程：

1. 事務 1 要插入 id = 5 的記錄，先查詢數(shù)據(jù)庫，發(fā)現(xiàn)不存在 id = 5 的數(shù)據(jù)，可以正常插入。

2. 這時候事務 2 插入了一條數(shù)據(jù) id = 5。

3. 事務 1 插入 id = 5 時，發(fā)現(xiàn)報錯唯一性沖突，對事務 1 來講就好像見了鬼了，我剛剛明明檢查過沒有，怎么這時候又有了。
   

事務隔離級別

串行化的事務處理方式當然是最安全的，但是串行無法滿足數(shù)據(jù)庫高并發(fā)訪問的需求，作為妥協(xié)，有時不得不降低數(shù)據(jù)庫的隔離標準來換取事務的并發(fā)能力，通過在可控的范圍內犧牲正確性來換取效率的提升，這種權衡通過事務的隔離級別來實現(xiàn)。

數(shù)據(jù)庫有 4 種事務隔離級別，由低到高依次為 讀未提交 Read Uncommitted 、讀已提交 Read Committed 、可重復讀 Repeatable Read 、串行化 Serializable 。

1. 讀未提交 Read Uncommitted
   允許讀取未提交的內容，這種級別下的查詢不會加鎖，因此臟讀、不可重復讀、幻讀都有可能發(fā)生。

2. 讀已提交 Read Committed
   只允許讀取已提交的內容，這種級別下的查詢不會發(fā)生臟讀，因為臟數(shù)據(jù)屬于未提交的數(shù)據(jù)，所以不會被讀取，但是依然有可能發(fā)生不可重復讀和幻讀。

3. 可重復讀 Repeatable Read （MySQL 的默認隔離級別）
   使用行級鎖來保證一個事務在相同查詢條件下兩次查詢得到的數(shù)據(jù)結果一致，可以避免臟讀和不可重復讀，但是沒有辦法避免幻讀。

   需要特殊注意的是，Innodb 在 Repeatable Read 下通過 MVCC 提供了穩(wěn)定的視圖，因此 Innodb 的 RR 隔離級別下是不會出現(xiàn)上述幻讀異常中的第一個場景的，但第二個場景還是會出現(xiàn)。

4. 串行化 Serializable
   使用表級鎖來保證所有事務的串行化，可以防止所有的異常情況，但是犧牲了系統(tǒng)的并發(fā)性。

查看隔離級別的命令為

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事務的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。