背景

說的事務(wù)，大家應(yīng)該都不陌生，開發(fā)用到 MySql 數(shù)據(jù)庫的時候，通常會用到事務(wù)。其中比較經(jīng)典的例子就是轉(zhuǎn)賬，比如你要給小明轉(zhuǎn) 50 塊錢，而此時你的銀行卡也就只有 50 塊錢。

對于轉(zhuǎn)賬過程在代碼程序里會有一系列的操作，比如查詢賬戶余額、余額加減、更新余額等，這些操作必須保證是一起處理的，不然等程序查完之后，如果賬號 50 塊錢還在，然后再給另外一個朋友轉(zhuǎn)賬，如果銀行也處理的話，沒有保證整個流程數(shù)據(jù)一致性的話，這不就亂套了嗎？這時就要用到“事務(wù)”了。

事務(wù)介紹

簡單來說，事務(wù)就是要保證一組數(shù)據(jù)庫操作，要么全部執(zhí)行成功，要么全部都失敗。在 MySQL 中，事務(wù)支持是在引擎層（InnoDB）實現(xiàn)的。我們知道，MySQL 是一個支持多引擎的系統(tǒng)，但并不是所有的引擎都支持事務(wù)。比如 MySQL 原生的 MyISAM 引擎就不支持事務(wù)，這也是 MyISAM 被 InnoDB 取代的重要原因之一。

在這篇文章里，將會以 InnoDB 為例，說說 MySQL 在事務(wù)支持方面的一些實現(xiàn)，并基于原理給出相應(yīng)的實踐建議，通過這些說明，可以加深對 MySQL 事務(wù)原理的理解。

事務(wù)的隔離級別

提到事務(wù)，你肯定會想到 ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔離性、持久性），下面我們就來說說其中 I，也就是“隔離性”。

當(dāng)數(shù)據(jù)庫上有多個事務(wù)同時執(zhí)行的時候，就可能出現(xiàn)臟讀（dirty read）、不可重復(fù)讀（non-repeatable read）、幻讀（phantom read）的問題，為了解決這些問題，就有了“隔離級別”的概念。

在談隔離級別之前，你首先要知道，你隔離得越嚴(yán)實，效率就會越低。因此很多時候，我們都要在二者之間尋找一個平衡點。SQL 標(biāo)準(zhǔn)的事務(wù)隔離級別包括：讀未提交（readuncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（serializable ）。下面逐一為你解釋：

• 讀未提交是指，一個事務(wù)還沒提交時，它做的變更就能被別的事務(wù)看到。
• 讀提交是指，一個事務(wù)提交之后，它做的變更才會被其他事務(wù)看到。
• 可重復(fù)讀是指，一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)，總是跟這個事務(wù)在啟動時看到的數(shù)據(jù)是一致的。當(dāng)然在可重復(fù)讀隔離級別下，未提交變更對其他事務(wù)也是不可見的。
• 串行化，顧名思義是對于同一行記錄，“寫”會加“寫鎖”，“讀”會加“讀鎖”。當(dāng)出現(xiàn)讀寫鎖沖突的時候，后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成，才能繼續(xù)執(zhí)行。

其中“讀提交”和“可重復(fù)讀”比較難理解，所以打算用一個例子說明這幾種隔離級別。假設(shè)數(shù)據(jù)表 t_student 中只有一列，其中一行的值為 21，下面是按照時間順序執(zhí)行兩個事務(wù)的行為。

mysql> create table t_student(age int) engine=InnoDB;
mysql> insert into t_student(age) values(21);

在不同的隔離級別下，事務(wù) A 會有哪些不同的返回結(jié)果，也就是圖中 V1、V2、V3 的返回值分別是什么。若隔離級別是“讀未提交”， 則 V1 的值就是 22。這時候事務(wù) B 雖然還沒有提交，但是結(jié)果對于 A 來說是可見的。因此，V2、V3 也都是 22。

若隔離級別是“讀提交”，則 V1 是 21，V2 的值是 22。事務(wù) B 的更新在提交后對 A 才是可見的。所以， V3 的值也是 22。

若隔離級別是“可重復(fù)讀”，則 V1、V2 是 21，V3 是 22。之所以 V2 還是 21，遵循的就是這個原則：事務(wù)在執(zhí)行期間看到的數(shù)據(jù)前后必須是一致的。

若隔離級別是“串行化”，則在事務(wù) B 執(zhí)行“將 21 改成 22”的時候，會被鎖住。直到事務(wù) A 提交后，事務(wù) B 才可以繼續(xù)執(zhí)行。所以從 A 的角度看， V1、V2 值是 21，V3 的值是 22。

在實現(xiàn)上，數(shù)據(jù)庫里面會創(chuàng)建一個視圖，訪問的時候以視圖的邏輯結(jié)果為準(zhǔn)。在“可重復(fù)讀”隔離級別下，這個視圖是在事務(wù)啟動時創(chuàng)建的，整個事務(wù)存在期間都用這個視圖。

在“讀提交”隔離級別下，這個視圖是在每個 SQL 語句開始執(zhí)行的時候創(chuàng)建的。這里需要注意的是，“讀未提交”隔離級別下直接返回記錄上的最新值，沒有視圖概念；而“串行化”隔離級別下直接用加鎖的方式來避免并行訪問。

可以看到在不同的隔離級別下，數(shù)據(jù)庫行為是有所不同的。Oracle 數(shù)據(jù)庫的默認隔離級別其實就是“讀提交”，因此對于一些從 Oracle 遷移到 MySQL 的應(yīng)用，為保證數(shù)據(jù)庫隔離級別的一致，你一定要記得將 MySQL 的隔離級別設(shè)置為“讀提交”。

配置的方式是，將啟動參數(shù) transaction-isolation 的值設(shè)置成 READ-COMMITTED。你可以用 showvariables 來查看當(dāng)前的值。

mysql> show variables like 'transaction_isolation';

總的來說，存在即合理，哪個隔離級別都有它自己的使用場景，要根據(jù)自己的業(yè)務(wù)情況來定。有些人可能會問那什么時候需要“可重復(fù)讀”的場景呢？我們來看一個數(shù)據(jù)校對邏輯的案例。

假設(shè)你在管理一個銀行賬戶表，一個表存了每個月月底的余額，一個表存了賬單明細。這時候你要做數(shù)據(jù)校對，也就是判斷上個月的余額和當(dāng)前余額的差額，是否與本月的賬單明細一致。你一定希望在校對過程中，即使有用戶發(fā)生了一筆新的交易，也不影響你的校對結(jié)果。這時候使用“可重復(fù)讀”隔離級別就很方便。事務(wù)啟動時的視圖可以認為是靜態(tài)的，不受其他事務(wù)更新的影響。

事務(wù)隔離的實現(xiàn)

理解了事務(wù)的隔離級別，我們再來看看事務(wù)隔離具體是怎么實現(xiàn)的。這里我們展開說明“可重復(fù)讀”。在 MySQL 中，實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前一個狀態(tài)的值。

假設(shè)一個值從 1 被按順序改成了 2、3、4，在回滾日志（undo log）里面就會有類似下面的記錄：

當(dāng)前值是 4，但是在查詢這條記錄的時候，不同時刻啟動的事務(wù)會有不同的 read-view。如圖中看到的，在視圖 A、B、C 里面，這一個記錄的值分別是 1、2、4，同一條記錄在系統(tǒng)中可以存在多個版本，就是數(shù)據(jù)庫的多版本并發(fā)控制（MVCC）。對于 read-view A，要得到 1，就必須將當(dāng)前值依次執(zhí)行圖中所有的回滾操作得到。

同時你會發(fā)現(xiàn)，即使現(xiàn)在有另外一個事務(wù)正在將 4 改成 5，這個事務(wù)跟 read-viewA、B、C 對應(yīng)的事務(wù)是不會沖突的。
有人可能會問，回滾日志總不能一直保留吧，什么時候刪除呢？當(dāng)然在不需要的時候才刪除，也就是說，系統(tǒng)會判斷，當(dāng)沒有事務(wù)再需要用到這些回滾日志時，回滾日志會被刪除。

那么問題來了，什么時候才不需要了呢？就是當(dāng)系統(tǒng)里沒有比這個回滾日志更早的 read-view 的時候。

基于上面的說明，我們來討論一下為什么建議你盡量不要使用長事務(wù)。

首先長事務(wù)意味著系統(tǒng)里面會存在很老的事務(wù)視圖，由于這些事務(wù)隨時可能訪問數(shù)據(jù)庫里面的任何數(shù)據(jù)，所以這個事務(wù)提交之前，數(shù)據(jù)庫里面它可能用到的回滾記錄都必須保留，這就會導(dǎo)致大量占用存儲空間。

在 MySQL 5.5 及以前的版本，回滾日志是跟數(shù)據(jù)字典一起放在 ibdata 文件里的，即使長事務(wù)最終提交，回滾段被清理，文件也不會變小。我見過數(shù)據(jù)只有 10GB，而回滾段有 100GB 的庫，最終只好為了清理回滾段，需要重建整個庫。
除了對回滾段的影響，長事務(wù)還占用鎖資源，也可能拖垮整個庫。

事務(wù)啟動方式

前面提到的長事務(wù)有這些潛在風(fēng)險，建議當(dāng)然是盡量避免。其實很多時候業(yè)務(wù)開發(fā)同學(xué)并不是有意使用長事務(wù)，通常是由于誤用所致。MySQL 的事務(wù)啟動方式有以下幾種：

1. 顯式啟動事務(wù)語句， begin 或 start transaction。配套的提交語句是 commit，回滾語句是 rollback。
2. set autocommit=0，這個命令會將這個線程的自動提交關(guān)掉。意味著如果你只執(zhí)行一個 select 語句，這個事務(wù)就啟動了，而且并不會自動提交。這個事務(wù)持續(xù)存在直到你主動執(zhí)行 commit 或 rollback 語句，或者斷開連接。

有些客戶端連接框架會默認連接成功后先執(zhí)行一個 set autocommit=0 的命令。這就導(dǎo)致接下來的查詢都在事務(wù)中，如果是長連接，就導(dǎo)致了意外的長事務(wù)。

因此，建議總是使用 set autocommit=1, 通過顯式語句的方式來啟動事務(wù)。但是有的開發(fā)同學(xué)會糾結(jié)“多一次交互”的問題。對于一個需要頻繁使用事務(wù)的業(yè)務(wù)，第二種方式每個事務(wù)在開始時都不需要主動執(zhí)行一次 “begin”，減少了語句的交互次數(shù)。如果你也有這個顧慮，建議使用 commit work and chain 的語法。

在 autocommit 為 1 的情況下，用 begin 顯式啟動的事務(wù)，如果執(zhí)行 commit 則提交事務(wù)。如果執(zhí)行 commit work and chain，則是提交事務(wù)并自動啟動下一個事務(wù)，這樣也省去了再次執(zhí)行 begin 語句的開銷。同時帶來的好處是從程序開發(fā)的角度明確地知道每個語句是否處于事務(wù)中。你可以在 information_schema 庫的 innodb_trx 這個表中查詢長事務(wù)。

總結(jié)

主要講了 MySQL 的事務(wù)隔離級別的現(xiàn)象和實現(xiàn)，根據(jù)實現(xiàn)原理分析了長事務(wù)存在的風(fēng)險，以及如何用正確的方式避免長事務(wù)。理解了這些事務(wù)的原理，可以更好地使用 MySQL 的事務(wù)特性。

到此這篇關(guān)于MySql學(xué)習(xí)筆記之事務(wù)隔離級別的文章就介紹到這了,更多相關(guān)MySql事務(wù)隔離級別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！