MySql學(xué)習(xí)筆記之事務(wù)隔離級(jí)別詳解

背景

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

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

事務(wù)介紹

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

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

事務(wù)的隔離級(jí)別

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mysql> show variables like 'transaction_isolation';

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

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

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

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

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

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

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

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

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

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

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

事務(wù)啟動(dòng)方式

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

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

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

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

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

總結(jié)

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

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