從一個問題開始

最近銀行這個事情鬧的比較厲害啊，很多儲戶的錢放在銀行，就不翼而飛了，而銀行還不管不問，說是用戶的責(zé)任，打官司，用戶還能輸了，這就是“社會主義”。咱還是少發(fā)牢騷，多種樹，莫談國事。

說到銀行存錢，就不得不說一下從銀行取錢這件事情，從ATM機取錢這件簡單的事情，實際上主要分為以下幾個步驟：

登陸ATM機，輸入密碼；

連接數(shù)據(jù)庫，驗證密碼；

驗證成功，獲得用戶信息，比如存款余額等；

用戶輸入需要取款的金額，按下確認鍵；

從后臺數(shù)據(jù)庫中減掉用戶賬戶上的對應(yīng)金額；

ATM吐出錢；

用戶把錢拿走。

一個簡單的取錢，主要分為以上幾步。不知道大家有沒有“天真”的想過，如果在第5步中，后臺數(shù)據(jù)庫中已經(jīng)把錢減掉了，但是ATM還就是沒有吐出錢（雖然實際也發(fā)生過，但是畢竟是低概率事件），這該怎么辦？

關(guān)于這個問題，銀行系統(tǒng)的開發(fā)人員早就想過了，那么他們是怎么來搞定這個問題的呢？這就要說到今天總結(jié)的事務(wù)這個概念了。

簡單說說事務(wù)

對于上面的取錢這個事情，如果有一步出現(xiàn)了錯誤，那么就取消整個取錢的動作；簡單來說，就是取錢這7步，要么都完成，要么就啥也不做。在數(shù)據(jù)庫中，事務(wù)也是這個道理。

事務(wù)由一條或者多條sql語句組成，在事務(wù)中的操作，這些sql語句要么都執(zhí)行，要么都不執(zhí)行，這就是事務(wù)的目的。

對于事務(wù)而言，它需要滿足ACID特性，下面就簡要的說說事務(wù)的ACID特性。

A，表示原子性；原子性指整個數(shù)據(jù)庫事務(wù)是不可分割的工作單位。只有使事務(wù)中所有的數(shù)據(jù)庫操作都執(zhí)行成功，整個事務(wù)的執(zhí)行才算成功。事務(wù)中任何一個sql語句執(zhí)行失敗，那么已經(jīng)執(zhí)行成功的sql語句也必須撤銷，數(shù)據(jù)庫狀態(tài)應(yīng)該退回到執(zhí)行事務(wù)前的狀態(tài)；

C，表示一致性；也就是說一致性指事務(wù)將數(shù)據(jù)庫從一種狀態(tài)轉(zhuǎn)變?yōu)榱硪环N一致的狀態(tài)，在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性約束沒有被破壞；

I，表示隔離性；隔離性也叫做并發(fā)控制、可串行化或者鎖。事務(wù)的隔離性要求每個讀寫事務(wù)的對象與其它事務(wù)的操作對象能相互分離，即該事務(wù)提交前對其它事務(wù)都不可見，這通常使用鎖來實現(xiàn)；

D，持久性，表示事務(wù)一旦提交了，其結(jié)果就是永久性的，也就是數(shù)據(jù)就已經(jīng)寫入到數(shù)據(jù)庫了，如果發(fā)生了宕機等事故，數(shù)據(jù)庫也能將數(shù)據(jù)恢復(fù)。

總結(jié)了一些事務(wù)的基本概念，在MySQL中，事務(wù)還是分為很多中的，下面就來看看到底有哪些事務(wù)。

有哪些事務(wù)

你能想象到嗎？就這么個破事務(wù)還會分以下這么多種：

扁平事務(wù)；

帶有保存點的扁平事務(wù)；

鏈事務(wù)；

嵌套事務(wù)；

分布式事務(wù)。

現(xiàn)在就來對這些事務(wù)從概念的層面上進行簡單的總結(jié)一下。

扁平事務(wù)

扁平事務(wù)是最簡單的一種，也是實際開發(fā)中使用的最多的一種事務(wù)。在這種事務(wù)中，所有操作都處于同一層次，最常見的方式如下：

BEGIN WORK Operation 1 Operation 2 Operation 3 ... Operation N COMMIT WORK

或者是這種：

BEGIN WORK Operation 1 Operation 2 Operation 3 ... Operation N (Error Occured) ROLLBACK WORK

扁平事務(wù)的主要缺點是不能提交或回滾事務(wù)的某一部分，或者分幾個獨立的步驟去提交。比如有這樣的一個例子，我從呼和浩特去深圳，為了便宜，我可能這么干：

BEGIN WORK Operation1:呼和浩特---火車--->北京 Operation2:北京---飛機--->深圳 ROLLBACK WORK

但是，如果Operation1，從呼和浩特到北京的火車晚點了，錯過了航班，怎么辦？感覺扁平事務(wù)的特性，那我就需要回滾，我再回到呼和浩特，那么這樣成本是不是也太高了啊，所以就有了下面的第二種事務(wù)——帶有保存點的扁平事務(wù)。

帶有保存點的扁平事務(wù)

這種事務(wù)除了支持扁平事務(wù)支持的操作外，允許在事務(wù)執(zhí)行過程中回滾到同一事務(wù)中較早的一個狀態(tài)，這是因為可能某些事務(wù)在執(zhí)行過程中出現(xiàn)的錯誤并不會對所有的操作都無效，放棄整個事務(wù)不合乎要求，開銷也太大。保存點用來通知系統(tǒng)應(yīng)該記住事務(wù)當(dāng)前的狀態(tài)，以便以后發(fā)生錯誤時，事務(wù)能回到該狀態(tài)。

鏈事務(wù)

鏈事務(wù)，就是指回滾時，只能恢復(fù)到最近一個保存點；而帶有保存點的扁平事務(wù)則可以回滾到任意正確的保存點。

嵌套事務(wù)

看下面這個，你就能明白了，啥是嵌套事務(wù)：

BEGIN WORK SubTransaction1: BEGIN WORK SubOperationX COMMIT WORK SubTransaction2: BEGIN WORK SubOperationY COMMIT WORK ... SubTransactionN: BEGIN WORK SubOperationN COMMIT WORKCOMMIT WORK

這就是嵌套事務(wù)，在事務(wù)中再嵌套事務(wù)，位于根節(jié)點的事務(wù)稱為頂層事務(wù)。事務(wù)的前驅(qū)稱為父事務(wù)，其它事務(wù)稱為子事務(wù)。事務(wù)的前驅(qū)稱為父事務(wù)，事務(wù)的下一層稱為子事務(wù)。

子事務(wù)既可以提交也可以回滾，但是它的提交操作并不馬上生效，除非由其父事務(wù)提交。因此就可以確定，任何子事務(wù)都在頂層事務(wù)提交后才真正的被提交了。同理，任意一個事務(wù)的回滾都會引起它的所有子事務(wù)一同回滾。

分布式事務(wù)

分布式事務(wù)通常是指在一個分布式環(huán)境下運行的扁平事務(wù)，因此需要根據(jù)數(shù)據(jù)所在位置訪問網(wǎng)絡(luò)中的不同節(jié)點，比如：通過建設(shè)銀行向招商銀行轉(zhuǎn)賬，建設(shè)銀行和招商銀行肯定用的不是同一個數(shù)據(jù)庫，同時二者的數(shù)據(jù)庫也不在一個網(wǎng)絡(luò)節(jié)點上，那么當(dāng)用戶跨行轉(zhuǎn)賬，就是通過分布式事務(wù)來保證數(shù)據(jù)的ACID的。

MySQL中使用事務(wù)

理論總結(jié)的再好，終歸都要通過實踐來進行理解。下面就來說說MySQL中是如何使用事務(wù)的。

在MySQL命令行的默認設(shè)置下，事務(wù)都是自動提交的，即執(zhí)行SQL語句后就會馬上執(zhí)行COMMIT操作。因此要顯示地開啟一個事務(wù)須使用命令BEGIN或START TRANSACTION，或者執(zhí)行命令SET AUTOCOMMIT=0，用來禁止使用當(dāng)前會話的自動提交。

來看看我們可以使用哪些事務(wù)控制語句。

BEGIN或START TRANSACTION；顯示地開啟一個事務(wù)；

COMMIT；也可以使用COMMIT WORK，不過二者是等價的。COMMIT會提交事務(wù)，并使已對數(shù)據(jù)庫進行的所有修改稱為永久性的；

ROLLBACK；有可以使用ROLLBACK WORK，不過二者是等價的?；貪L會結(jié)束用戶的事務(wù)，并撤銷正在進行的所有未提交的修改；

SAVEPOINT identifier；SAVEPOINT允許在事務(wù)中創(chuàng)建一個保存點，一個事務(wù)中可以有多個SAVEPOINT；

RELEASE SAVEPOINT identifier；刪除一個事務(wù)的保存點，當(dāng)沒有指定的保存點時，執(zhí)行該語句會拋出一個異常；

ROLLBACK TO identifier；把事務(wù)回滾到標記點；

SET TRANSACTION；用來設(shè)置事務(wù)的隔離級別。InnoDB存儲引擎提供事務(wù)的隔離級別有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。

這些不用你“管”

有的時候有些SQL語句會產(chǎn)生一個隱式的提交操作，即執(zhí)行完成這些語句后，會有一個隱式的COMMIT操作。有以下SQL語句，不用你去“管”：

DDL語句，ALTER DATABASE、ALTER EVENT、ALTER PROCEDURE、ALTER TABLE、ALTER VIEW、CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE等；

修改MYSQL架構(gòu)的語句，CREATE USER、DROP USER、GRANT、RENAME USER、REVOKE、SET PASSWORD；

管理語句，ANALYZE TABLE、CACHE INDEX、CHECK TABLE、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE等。

以上的這些SQL操作都是隱式的提交操作，不需要手動顯式提交。

事務(wù)的隔離級別

上面也說到了SET TRANSACTION用來設(shè)置事務(wù)的隔離級別。那事務(wù)的隔離級別是什么東東？

在數(shù)據(jù)庫操作中，為了有效保證并發(fā)讀取數(shù)據(jù)的正確性，提出的事務(wù)隔離級別。

InnoDB存儲引擎提供事務(wù)的隔離級別有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。這些隔離級別之間的區(qū)別如下：

臟讀：一個事務(wù)讀取到了另外一個事務(wù)沒有提交的數(shù)據(jù)；

比如：事務(wù)T1更新了一行記錄的內(nèi)容，但是并沒有提交所做的修改。事務(wù)T2讀取到了T1更新后的行，然后T1執(zhí)行回滾操作，取消了剛才所做的修改?，F(xiàn)在T2所讀取的行就無效了；

不可重復(fù)讀：在同一事務(wù)中，兩次讀取同一數(shù)據(jù)，得到內(nèi)容不同；

比如：事務(wù)T1讀取一行記錄，緊接著事務(wù)T2修改了T1剛才讀取的那一行記錄。然后T1又再次讀取這行記錄，發(fā)現(xiàn)與剛才讀取的結(jié)果不同。這就稱為“不可重復(fù)”讀，因為T1原來讀取的那行記錄已經(jīng)發(fā)生了變化；

幻讀：同一事務(wù)中，用同樣的操作讀取兩次，得到的記錄數(shù)不相同；

比如：事務(wù)T1讀取一條指定的WHERE子句所返回的結(jié)果集。然后事務(wù)T2新插入 一行記錄，這行記錄恰好可以滿足T1所使用的查詢條件中的WHERE子句的條件。然后T1又使用相同的查詢再次對表進行檢索，但是此時卻看到了事務(wù)T2剛才插入的新行。這個新行就稱為“幻像”，因為對T1來說這一行就像突然出現(xiàn)的一樣。

隔離級別越低，事務(wù)請求的鎖越少或保持鎖的時間就越短。InnoDB存儲引擎默認的支持隔離級別是REPEATABLE READ；在這種默認的事務(wù)隔離級別下已經(jīng)能完全保證事務(wù)的隔離性要求，即達到SQL標準的SERIALIZABLE級別隔離。

我們可以可以用SET TRANSACTION語句改變單個會話或者所有新進連接的隔離級別。它的語法如下：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

注意：默認的行為（不帶session和global）是為下一個（未開始）事務(wù)設(shè)置隔離級別。如果使用GLOBAL關(guān)鍵字，語句在全局對從那點開始創(chuàng)建的所有新連接（除了不存在的連接）設(shè)置默認事務(wù)級別。你需要SUPER權(quán)限來做這個。使用SESSION 關(guān)鍵字為將來在當(dāng)前連接上執(zhí)行的事務(wù)設(shè)置默認事務(wù)級別。 任何客戶端都能自由改變會話隔離級別（甚至在事務(wù)的中間），或者為下一個事務(wù)設(shè)置隔離級別。

mysql> set session transaction isolation level repeatable read; Query OK, 0 rows affected (0.00 sec) mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec)

總結(jié)

這篇文章，基本上都是理論概念的堆積，實戰(zhàn)的東西基本沒有。但是，這些都不是問題，這也無法阻擋這篇文章成為一篇讀者喜歡的文章，是吧。好了，這篇關(guān)于MySQL中事務(wù)的文章就到此結(jié)束，以后如果有新的東西，就接著總結(jié)。

更多信息請查看IT技術(shù)專欄